வேர்ட்பிரஸ் "மரண பிழை" தீர்வு: உங்கள் வலைத்தளத்தை இடிந்து போகச் செய்யும் உதிரியை கண்டுபிடிக்கவும்

வேர்ட்பிரஸ் மரண பிழையை தீர்க்கவேண்டிய மிக விரைவு மற்றும் அமைதியான முறை, முதலில் வலைத்தளத்தை அணுகக்கூடியதாக மாற்றுவது, பின்னர் சந்தேகத்திற்குட்பட்ட உதிரிகளை ஒவ்வொன்றாக தனிமைப்படுத்தி கண்டுபிடிப்பதாகும். பொதுவாக, பிழை; பொருந்தாத உதிரி அப்டேட், PHP பதிப்பு மோதல், தீமை மற்றும் உதிரி இடையே செயல்பாட்டு மோதல் அல்லது நினைவகம் குறைவாக இருப்பதன் மூலம் ஏற்படுகிறது. நீங்கள் நிர்வாக குழுவிற்கு அணுக முடியாதால், FTP, கோப்பு மேலாளர் அல்லது ஹோஸ்டிங் கட்டுப்பாட்டு குழுவின் மூலம் உதிரி அடைவை தற்காலிகமாக முடக்கலாம், பின்னர் பிழை பதிவுகளில் எந்த உதிரி உங்கள் வலைத்தளத்தை இடிந்து போகச் செய்தது என்பதை தெளிவாக கண்டுபிடிக்கலாம்.

இந்த வழிகாட்டியில், வேர்ட்பிரஸ் வலைத்தளத்தில் தோன்றும் மரண பிழையை அச்சமடையாமல் எப்படி பகுப்பாய்வு செய்வது, உங்கள் வலைத்தளத்தை இடித்து விடும் உதிரியை எப்படி கண்டுபிடிக்க வேண்டும் மற்றும் ஒரே மாதிரியான சிக்கல்களை மீண்டும் அனுபவிக்காமல் இருப்பதற்கான நிரந்தர முன்னெச்சரிக்கைகளை எப்படித் தெரிந்து கொள்ள வேண்டும் என்பதைக் கட்ட வாரியமாகவும் விளக்குகிறோம். விளக்கமே, தொழில்நுட்ப அறிவு இருக்காத வலைத்தள உரிமையாளர்களும் செயல்படுத்தக்கூடிய அளவுக்கு நடைமுறையாகவும்; வளர்த்தவர்கள் மற்றும் முகவரிகள் கட்டுப்பாட்டு பட்டியலாகப் பயன்படுத்தக்கூடிய அளவுக்கு விவரமாகவும் தயாரிக்கப்பட்டுள்ளது.

வேர்ட்பிரஸ் மரண பிழை என்றால் என்ன?

வேர்ட்பிரஸ் மரண பிழை, PHP பக்கம் செயல்பட முடியாத அளவுக்கு நெருக்கமான பிழை ஏற்படும் போது தோன்றும் இடிந்து போகும் நிலை ஆகும். இந்த பிழை சில சமயம் வெள்ளை திரை, சில சமயம் "மரண பிழை ஏற்பட்டுள்ளது" என்ற செய்தி மட்டும், அல்லது குறிப்பிட்ட PHP கோப்பை குறிக்குமாறு தொழில்நுட்ப பிழை வெளியீடு ஆக இருக்கலாம். வேர்ட்பிரஸ் மூலக் கோரிக்கைகள், தீமை கோப்புகள் மற்றும் உதிரிகள் PHP உடன் செயல்படுவதால், ஒரே பொருந்தாத குறியீட்டு வரி முழு வலைத்தளத்தின் திறப்பை தடுக்கும்.

உதாரணமாக, ஒரு உதிரி PHP 8.2 உடன் பொருந்தவில்லை என்றால், நீங்கள் ஹோஸ்டிங் பக்கம் PHP பதிப்பை மேம்படுத்தும் போது, வலைத்தளம் மரண பிழை தரலாம். இதே போல, இரண்டு வெவ்வேறு உதிரிகள் ஒரே செயல்பாட்டை வரையறுக்க முயற்சித்தால், வேர்ட்பிரஸ் அந்த செயல்பாட்டை இரண்டாவது முறையாக ஏற்ற முடியாததால் செயல்படுத்தக் கூடாது. எனவே, பிழை செய்தியில் காணப்படும் கோப்பு பாதை மிகவும் முக்கியமானது. பாதை wp-content/plugins/உதிரி-பெயர் என்ற வடிவில் தொடர்ந்தால், சிக்கல் பெரும்பாலும் தொடர்புடைய உதிரியால் தான் ஆக இருக்க வாய்ப்பு உள்ளது.

மரண பிழையின் அறிகுறிகள் மற்றும் முதன்மை கட்டுப்பாட்டு புள்ளிகள்

மரண பிழை எப்பொழுதும் ஒரே திரையில் தோன்றவில்லை. வேர்ட்பிரஸ் 5.2 மற்றும் அதைத் தொடர்ந்து பதிப்புகளில் பல முக்கிய பிழைகள், வலைத்தள மேலாளருக்கு மின்னஞ்சல் மூலம் மீட்பு முறை இணைப்பை அனுப்புவதன் மூலம் நிர்வகிக்கலாம். ஆனால் மின்னஞ்சல் கிடைக்கவில்லை என்றால் அல்லது பிழை மிகவும் முந்தைய நிலைமையில் உருவாகினால், கையினால் தலையீடு தேவைப்படுகிறது. கீழ்காணும் அறிகுறிகள், உதிரி மூலம் ஏற்பட்ட மரண பிழையின் வாய்ப்புகளை அதிகரிக்கின்றன:

• வலைத்தள முன்னணி முற்றிலும் வெள்ளை திரையில் நீடிக்கும்.
• நிர்வாக குழுவிற்குள் புகுத்தும் போது "மரண பிழை ஏற்பட்டுள்ளது" என்ற எச்சரிக்கை தோன்றுகிறது.
• ஒரு குறிப்பிட்ட பக்கம், உதாரணமாக கட்டணம் பக்கம் அல்லது தொடர்பு படிவம் திறக்கும்போது வலைத்தளம் இடிந்து போகிறது.
• கடைசி செய்யப்பட்ட உதிரி அப்டேடிற்குப் பிறகு உடனே பிழை ஆரம்பிக்கிறது.
• பிழை செய்தியில் wp-content/plugins அடைவில் ஒரு கோப்புப் பெயர் தோன்றுகிறது.
• சர்வர் பிழை பதிவுகளில் PHP மரண பிழை வரிகள் மீண்டும் மீண்டும் தோன்றுகின்றன.

முதலாவது கட்டுப்பாட்டைச் செய்யும்போது, கடந்த 24 மணிநேரத்தில் என்ன மாறின என்பதைக் குறித்துக் கொள்ளுங்கள். புதிய உதிரி நிறுவப்பட்டது, உள்ளமைவுள்ள உதிரி புதுப்பிக்கப்பட்டதா, PHP பதிப்பு மாறியதா, தீமை புதுப்பிக்கப்பட்டதா, பாதுகாப்பு உதிரி புதிய விதிகள் சேர்த்ததா? அனுபவத்தில் அடிக்கடி காணப்படும் காட்சி, தானாகவே புதுப்பிக்கப்படும் உதிரி, பயன்படுத்தப்படும் தீமை அல்லது PHP பதிப்புடன் பொருந்தாததாக மாறுகிறது.

விரைவு கண்டறிதல் அட்டவணை: பிழை எங்கு இருந்து வருகிறது?

இந்த அட்டவணை விரைவு வழிகாட்டுவதற்காகவே உள்ளது. இறுதி முடிவுக்கு, பிழை பதிவுகளை அவசியமாக ஆய்வு செய்ய வேண்டும் மற்றும் சிக்கல் உள்ள உதிரியை கட்டுப்படுத்தப்பட்ட முறையில் சோதிக்க வேண்டும். குறிப்பாக, மின் வணிக வலைத்தளங்களில் தற்செயலாக கோப்புகளை அழித்தால், ஆர்டர் செயல்முறைகள் மற்றும் கட்டண ஒருங்கிணைப்புகளை பாதிக்கக்கூடும்.

செயல்முறை தொடங்குவதற்கு முன்பு பாதுகாப்பான தயாரிப்பு

மரண பிழை ஏற்பட்ட போது மிகப் பெரிய பிழை, பதற்றத்தில் கோப்புகளை அழிப்பது அல்லது தரவுத்தளத்தில் அக்கறையின்றி செயல்படுவதாகும். முதலில் மீட்பு வாய்ப்புகளை உறுதி செய்யுங்கள். நேர்மறை இணையதளத்தில் நீங்கள் செய்யும் ஒவ்வொரு தலையீடும், குறிப்பாக வூகாமர்ஸ், உறுப்பினர் அமைப்பு அல்லது முன்பதிவு முறை போன்ற இயக்கம் செய்யப்பட்ட தகவல்களைப் பயன்படுத்தும் அமைப்புகளில் தரவுப் போக்கின் ஆபத்தை ஏற்படுத்துகிறது.

• 1. முழுமையான காப்பீடு எடுக்கவும்: கோப்புகள் மற்றும் தரவுத்தளம் ஒன்றாக காப்பீடு செய்யப்பட வேண்டும். மட்டும் public_html அடைவைக் காப்பீடு செய்வது போதுமானது அல்ல.
• 2. பிழை நேரத்தை குறிக்கவும்: சிக்கல் தொடங்கிய நேரம், சர்வர் லாக்களில் சரியான வரிக்கு உங்கள் செல்லுத்திற்குப் போக உதவுகிறது.
• 3. கடைசி மாற்றங்களை பட்டியலிடுங்கள்: புதுப்பிக்கப்பட்ட உதிரிகள், PHP பதிப்பு, தீமை மாற்றங்கள் மற்றும் புதிய குறியீட்டு சேர்ப்புகளைப் பதிவு செய்ய வேண்டும்.
• 4. தேவையெனில் staging சூழலைப் பயன்படுத்தவும்: நேர்மறை வலைத்தளத்தைப் பதிப்புக்கு மாற்றுவதற்குப் பதிலாக நகல் சூழலில் சோதனை செய்வது பாதுகாப்பானது. WordPress ஹோஸ்டிங்
• 5. நிர்வாக அணுகலைச் சரிபார்க்கவும்: FTP, ஹோஸ்டிங் குழு மற்றும் தரவுத்தள அணுகல் உங்கள் கையினில் இருக்க வேண்டும்.

தொழில்முறை ஹோஸ்டிங் அடிப்படையில், தினசரி காப்பீடு, எளிய கோப்பு மேலாளர், PHP பதிப்பு மாற்றம் மற்றும் பிழை பதிவுகளுக்கு அணுகல் போன்றவை சிக்கலை சில நிமிடங்களில் தீர்க்க உதவுகிறது. எனவே, வேர்ட்பிரஸ் வலைத்தளங்களில் காப்பீடு மட்டுமே அல்ல, நிர்வாக கருவிகள் மற்றும் தொழில்நுட்ப ஆதரவு தரத்துக்கும் கவனம் செலுத்தப்பட வேண்டும். வலை உருவாக்குதல்

கட்டுக்கோலால் வேர்ட்பிரஸ் மரண பிழையை தீர்க்கவும்

1. வேர்ட்பிரஸ் மீட்பு முறை மின்னஞ்சலைச் சரிபார்க்கவும்

வேர்ட்பிரஸ் முக்கிய பிழை கண்டுபிடித்தால், வலைத்தள மேலாளரின் பதிவுசெய்த மின்னஞ்சல் முகவரிக்கு மீட்பு முறை இணைப்பை அனுப்பலாம். இந்த இணைப்பு, சிக்கலான உதிரியை நிர்வாக குழுவில் இருந்து முடக்க உங்களுக்கு அனுமதிக்கும். உள்நுழைவுப் பெட்டி, ஸ்பாம் கோப்பகம் மற்றும் மின்னஞ்சல் வழிமுறைகளை சரிபார்க்கவும். மின்னஞ்சலில் பொதுவாக எந்த உதிரி பிழையை ஏற்படுத்தியதற்கான தகவலையும் காணலாம்.

மீட்பு முறை செயல்படுவதாக இருந்தால், செயல்முறை மிகவும் எளிதாக இருக்கும்: இணைப்பை கிளிக் செய்யவும், வேர்ட்பிரஸ் நிர்வாக குழுவிற்குள் புகுத்தவும், உத்திரவாதமான உதிரியை நிர்வாக குழுவின் உதிரிகள் பக்கம் இருந்து முடக்கவும், மேலும் வலைத்தளம் திறக்கிறதா என்பதைப் பார்க்கவும். பின்னர், உதிரியை உடனே மீண்டும் செயல்படுத்துவது அல்லது புதுப்பிப்பு பதிவுகளை, ஆதரவு மன்றங்களை மற்றும் PHP பொருத்தத்தை ஆய்வு செய்யுங்கள்.

2. நிர்வாக குழுவிற்கு அணுக முடியாதால் அனைத்து உதிரிகளை முடக்கவும்

நிர்வாக குழு திறக்கவில்லை என்றால், மிகவும் நடைமுறை முறை, wp-content/plugins அடைவின் பெயரை தற்காலிகமாக மாற்றுவது. FTP கிளயிண்ட், SSH அல்லது ஹோஸ்டிங் கோப்பு மேலாளர் மூலம் public_html/wp-content அடைவிற்கு செல்லவும். plugins அடைவை plugins-pasif என்ற முறையில் மீண்டும் பெயரிடுங்கள். வேர்ட்பிரஸ் இந்த அடையை கண்டுபிடிக்க முடியவில்லை என்பதால், அனைத்து உதிரிகளையும் முடக்கிவிடும்.

இந்த செயல்முறை தரவுத்தளத்தில் உள்ள உதிரி அமைப்புகளை அழிக்காது; வெறும் உதிரிகளை ஏற்றி விடுவதை நிறுத்தும். வலைத்தளம் திறந்தால், மரண பிழை பெரும்பாலும் உதிரிகளால் வந்துள்ளது. பின்னர், அடைவு பெயரை மீண்டும் plugins என்ற முறையில் மாற்றுங்கள். இந்த முறையில், அடைவின் உள்ளே உள்ள உதிரி அடைகளை தனித்தனியாக மீண்டும் பெயரிடுவதன் மூலம் அல்லது நிர்வாக குழுவில் தனித்தனியாக செயல்படுத்துவதன் மூலம் சிக்கலான உதிரியை கண்டுபிடிக்கலாம்.

• wp-content/plugins அடைவைக் plugins-pasif ஆக மாற்றவும்.
• வலைத்தளத்தை மறைமுகமான திரையில் சோதிக்கவும்.
• வலைத்தளம் திறந்தால், அடைவு பெயரை மீண்டும் plugins ஆக மாற்றவும்.
• உதிரிகளை தனித்தனியாக செயல்படுத்தவும்.
• பிழை மீண்டும் வந்தால், கடைசி செயல்படுத்திய உதிரியை குறிக்கவும்.

இந்த முறை எளிதாகத் தோன்றினாலும், ஒரு திறமையான தனிமைப்படுத்தல் சோதனை ஆகும். குறிப்பாக, 20 அல்லது அதற்கு மேற்பட்ட உதிரிகளைப் பயன்படுத்தும் வலைத்தளங்களில், உதிரிகளை அகர வரிசையில் அல்லாமல், கடைசி புதுப்பிக்கப்பட்டவற்றில் இருந்து தொடங்குவதால் நேரத்தைச் சேமிக்கிறது.

3. சிக்கலான உதிரியை தனித்தனியாக தனிமைப்படுத்தவும்

வலைத்தளம் அனைத்து உதிரிகள் மூடப்பட்டிருந்தால் திறக்கிறது, ஆனால் குறிப்பிட்ட ஒரு உதிரி திறக்கும்போது இடிந்து போகும் என்றால், நீங்கள் சிக்கலை கண்டுபிடித்ததாகக் கருதலாம். இருப்பினும், அதிரடி முடிவெடுக்காதீர்கள். சில சமயங்களில், இரண்டு உதிரிகள் ஒரே நேரத்தில் செயல்படும்போது பிழை ஏற்படலாம்; தனியாக செயல்படுத்தும்போது சிக்கலாக இருக்காது. அதனால், இரட்டை மோதல்களை சோதிக்கவும்.

உதாரண காட்சி: ஒரு பாதுகாப்பு உதிரி மற்றும் கச்சிதமாக்கும் உதிரி ஒரே கோப்பு அனுமதிகளை பாதிக்கக்கூடும். அல்லது வூகாமர்ஸ் உதிரி புதுப்பிக்கப்பட்டுள்ளது, ஆனால் கட்டண நுழைவுத்தொகுப்பின் உதிரி பழையதாக இருப்பதால் மரண பிழை ஏற்படுகிறது. இந்த நிலையில், பிழை வூகாமர்ஸ் உடன் தோன்றினாலும், உண்மையான குற்றவாளி கட்டண உதிரி ஆக இருக்கக்கூடும்.

• முதலில், அடிப்படை உதிரிகளை செயல்படுத்துங்கள்: வூகாமர்ஸ், SEO உதிரி, படிவ உதிரி போன்ற வலைத்தளத்தின் அடிப்படை செயல்பாடுகள்.
• பின்னர், உதவிய உதிரிகளை திறக்கவும்: கச்சிதமாக்கும், பாதுகாப்பு, மறுவரைபு, காட்சியகம், சமூக பகிர்வு.
• ஒவ்வொரு செயல்படுத்துதலுக்கும் பிறகு, வலைத்தளத்தின் முன்னணி மற்றும் நிர்வாக குழுவுக்குள் சோதிக்கவும்.
• கட்டணம், கொள்கை, தொடர்பு படிவம் மற்றும் உறுப்பினர் நுழைவு போன்ற முக்கிய பக்கங்களை கூடுதல் சோதிக்கவும்.
• பிழை மீண்டும் வந்தால், கடைசி செயல்படுத்திய உதிரியின் தகவல்களை மற்றும் பிழை செய்தியை பதிவு செய்யுங்கள்.

இந்த கட்டத்தில், உங்கள் நோக்கம் வெறும் வலைத்தளத்தை திறக்கவில்லை; முதல் காரணத்தை சரியாக கண்டு பிடிக்க வேண்டும். தவறான உதிரியை குற்றவாளியாகக் கூறுவது, சில நாட்களில் மீண்டும் சிக்கலை சந்திக்கச் செய்யலாம்.

4. பிழை பதிவுகளிலிருந்து உறுதியான ஆதாரங்களை சேகரிக்கவும்

சர்வரின் பிழை பதிவுகள், மரண பிழை தீர்வில் மிகப் சக்திவாய்ந்த ஆதாரம் ஆகும். ஹோஸ்டிங் கட்டுப்பாட்டு குழுவில் பிழை பதிவு, பிழை பதிவுகள் அல்லது இதற்கான சமமான பகுதி காணப்படுகிறது. மேலும், வேர்ட்பிரஸ் பக்கம் wp-config.php கோப்பில் debug அமைப்புகளைச் சேர்ப்பதன் மூலம் wp-content/debug.log கோப்பை உருவாக்கலாம்.

உருவாக்கம் அல்லது தற்காலிக கண்டறிதலுக்கு, கீழ்காணும் முறைமையைப் பயன்படுத்தலாம்: WP_DEBUG செயல்படுத்தப்படுகிறது, பிழைகள் திரையில் இல்லை, பதிவு கோப்பில் எழுதப்படுகிறது, பின்னர் வலைத்தளம் மீண்டும் சோதிக்கப்படுகிறது. திரையில் பிழைகளை பதிவு செய்வது நேர்மறை இணையதளங்களில் பாதுகாப்பு ஆபத்தை ஏற்படுத்தக்கூடும்; கோப்பு பாதை, பயனர் பெயர் அல்லது சர்வர் அமைப்புகள் போன்ற தகவல்கள் பார்வையாளர்களுக்கு தெரியக்கூடாது.

பதிவுகளில் குறிப்பாக அடுத்த உரைகள் தேடுங்கள்: PHP மரண பிழை, அடிக்கடி பிழை, require_once தோல்வி, allowed memory size exhausted, undefined function க்கு அழைப்பு, re-declare முடியாது. வரியின் தொடரில் கோப்பு பாதை மற்றும் வரி எண் காணப்படும். எடுத்துக்காட்டாக, wp-content/plugins/ornek-eklenti/includes/class-loader.php on line 214 என்ற உரை, ornek-eklenti அடைவில் உள்ள ஒரு கோப்பு பிழையை உருவாக்குவதாகக் குறிக்கிறது.

பிழை பதிவுகளைப் படிக்குவது முதலில் சிக்கலாக இருக்கலாம், ஆனால் பெரும்பாலும் கோப்பு பாதையில் உள்ள உதிரியின் பெயர் உங்களுக்கு நேரடியாக ஒரு குறிக்கோளை தரும். Hostragons கட்டுப்பாட்டு குழுவில் பிழை பதிவுகளுக்கு அணுகல், PHP பதிப்பு மேலாண்மை மற்றும் கோப்பு தலையீடு போன்ற செயல்களை ஒரே இடத்தில் செய்யலாம். விற்பனை கட்டுப்பாட்டு சான்றிதழ்

5. PHP பதிப்பு மற்றும் நினைவக வரம்புகளைச் சரிபார்க்கவும்

ஒவ்வொரு மரண பிழையும் உடனடியாக குறைந்த உதிரியை குறிக்காது. உதிரி, நீங்கள் பயன்படுத்தும் PHP பதிப்புடன் பொருந்தாததாக இருக்கலாம். 2026க்கு பிறகு, நவீன வேர்ட்பிரஸ் நிறுவல்களில் சமீபத்திய PHP பதிப்புகள் செயல்திறன் மற்றும் பாதுகாப்பு அடிப்படையில் முக்கியம்; ஆனால் பழைய உதிரிகள் சில புதிய PHP நடத்தை ஆதரிக்க முடியாது. இதற்கு மாறாக, மிகவும் பழைய PHP பதிப்பில் செயல்படும் ஒரு வலைத்தளம், புதிய உதிரி தேவைப்படும் செயல்பாடுகளை ஆதரிக்கவில்லை என்பதால் இடிந்து போகலாம்.

PHP நினைவக வரம்பும் அடிக்கடி காணப்படும் ஒரு காரணமாகும். குறிப்பாக, பல மொழிகளில் உள்ள வலைத்தளங்கள், வூகாமர்ஸ் கடைகள், பக்கம் உருவாக்கிகள் மற்றும் அதிக பாதுகாப்பு சோதனைச் செய்யும் உதிரிகள் அதிக நினைவகத்தைப் பயன்படுத்துகின்றன. பிழை வரியில் Allowed memory size exhausted எழுதப்பட்டால், உதிரி தனியாக அழிவாக இருக்கக்கூடாது; தற்போதைய ஆதார வரம்பு குறைவாக இருக்கலாம்.

• சிறிய நிறுவன வேர்ட்பிரஸ் வலைத்தளங்களுக்கு 256 MB PHP memory_limit பெரும்பாலும் போதுமானது.
• வூகாமர்ஸ் அல்லது உறுப்பினர் வலைத்தளங்களில் 512 MB என்பது மிகவும் பாதுகாப்பான ஆரம்ப மதிப்பாகும்.
• அதிக பரிசோதனை அல்லது பல உதிரிகள் உள்ள அமைப்புகளில் ஆதார திட்டம் கூடுதல் மதிப்பீடு செய்யப்பட வேண்டும்.
• PHP பதிப்பை மாற்றும்போது முதலில் staging சூழலில் சோதனை செய்ய வேண்டும்.

ஆதார சிக்கல்களும் அடிக்கடி நிகழ்ந்தால், நினைவகத்தை அதிகரிப்பதை மட்டுமே செய்யாமல், உதிரிகள் எண்ணிக்கையை, தரவுத்தளம் வினவல்களை மற்றும் ஹோஸ்டிங் தொகுப்பினைப் பரஸ்பரம் மதிப்பீடு செய்யுதல் மிகவும் ஆரோக்கியமாக இருக்கும். WordPress ஹோஸ்டிங் தொகுப்புகள்

நிர்வாக குழு திறக்கவில்லை என்றால் பயன்படுத்தக்கூடிய மாற்று முறைகள்

FTP அல்லது கோப்பு மேலாளர் மூலம் உதிரி அடையை மாற்றவும்

மிகவும் நம்பகமான கையினால் முறை, உதிரி அடைவைப் பெயரிடுவது ஆகும். சிக்கலான உதிரி தெளிவாக இருந்தால், அனைத்து plugins அடைவுகளை முடக்காமல், உரிய உதிரியின் அடைவை மட்டும் பெயரிடலாம். எடுத்துக்காட்டாக, wp-content/plugins/siteyi-cokerten-eklenti அடையை siteyi-cokerten-eklenti-pasif ஆக மாற்றுவது போதுமானது. வேர்ட்பிரஸ் அந்த உதிரியை ஏற்ற முடியாது, எனவே பிழை நீக்கப்படலாம்.

இந்தச் செயல்முறைக்குப் பிறகு, நிர்வாக குழுவில் அணுகி, உதிரிகள் பக்கத்தைத் திறந்தால், வேர்ட்பிரஸ் தொடர்புடைய உதிரியை முடக்கப்பட்டதாகக் குறிக்கிறது. அடைவை மீண்டும் பெறுவதற்கு முன், உதிரியின் புதிய பதிப்பை, வளர்த்தவர் குறிப்புகளை மற்றும் ஆதரவு கோரிக்கைகளை ஆய்வு செய்யுங்கள். தேவையெனில், உதிரியின் முந்தைய நிலையான பதிப்பில் திரும்புங்கள்.

WP-CLI மூலம் உதிரியை முடக்கவும்

SSH அணுகல் இருந்தால், WP-CLI என்பது தொழில்முறை மற்றும் விரைவு தீர்வாகும். கட்டளை வரியிலிருந்து அனைத்து உதிரிகளை பட்டியலிடலாம், குறிப்பிட்ட ஒரு உதிரியை முடக்கலாம் அல்லது அனைத்தையும் ஒரே நேரத்தில் மூடலாம். எடுத்துக்காட்டாக, அனைத்து உதிரிகளை மூடிக் கொண்டு வலைத்தளத்தை சோதிப்பது, பின்னர் தனித்தனியாக செயல்படுத்துவது சில நிமிடங்களில் முடிகிறது.

WP-CLI பயன்படுத்தும் போது, நீங்கள் சரியான வேர்ட்பிரஸ் அடைவில் இருப்பதை உறுதிப்படுத்துங்கள். தவறான அடையில் கட்டளைகளை செயல்படுத்துவது முடிவு தராமல் இருக்கலாம் அல்லது வேறு ஒரு நிறுவலில் செயல்படச் செய்யலாம். முகவர்கள் மற்றும் வளர்த்தவர்களுக்கு இந்த முறை, பல வேர்ட்பிரஸ் வலைத்தளங்களில் தரவுத்தளத்துக்கான சிக்கல்களை தீர்க்குவதில் ஒரு பகுதியாக இருக்க வேண்டும்.

தரவுத்தளத்தில் செயல்பாட்டுத்தொகுப்புகளை மீட்டமைக்க

கடைசி தீர்வாக, தரவுத்தளத்தில் active_plugins மதிப்பை மாற்றலாம். இந்த செயல்முறை பொதுவாக phpMyAdmin மூலம் wp_options அட்டவணையில் செய்யப்படுகிறது. இருப்பினும், குறிப்பிட்ட தரவுத்தளம் அமைப்பு சிதைவுக்கு உள்ளானால், புதிய பிழைகள் உருவாகலாம். எனவே, தரவுத்தள செயல்முறைகள், காப்பீடு எடுத்த பிறகு மற்றும் என்ன செய்வதைப் பற்றிய அறிவு உள்ளவர்கள் மட்டுமே செய்ய வேண்டும்.

உங்களிடம் தொழில்நுட்ப அறிவு குறைவாக இருந்தால், தரவுத்தளத்திற்கு பதிலாக, அடைவு பெயரை மாற்றும் முறையைத் தேர்ந்தெடுக்கவும். கோப்பு அமைப்பின் வழியாக செய்யப்பட்ட தற்காலிக முடக்கம், பெரும்பாலான வலைத்தள உரிமையாளர்களுக்கு மிகவும் குறைவான ஆபத்துடன் இருக்கும்.

சிக்கலான உதிரியை கண்டுபிடித்த பிறகு என்ன செய்ய வேண்டும்?

மரண பிழையை ஏற்படுத்தும் உதிரியை முடக்குவது உங்கள் வலைத்தளத்தை மீட்டெடுக்கிறது; இருப்பினும், நிலையான தீர்விற்கு, உதிரி ஏன் பிழை உண்டாக்கியது என்பதைப் புரிந்துகொள்ள வேண்டும். இல்லையெனில், அதே உதிரியை மீண்டும் செயல்படுத்தினால் அல்லது தானாகவே புதுப்பிக்கையில், வலைத்தளம் மீண்டும் இடிந்து போகலாம்.

• உதிரியின் கடைசி பதிப்பு குறிப்புகளைப் படிக்கவும். வளர்த்தவர் பொருத்தம் அல்லது பிழை திருத்தத்தை வெளியிட்டிருக்கலாம்.
• வேர்ட்பிரஸ் மூல பதிப்பைச் சரிபார்க்கவும். மிகவும் பழைய மூல பதிப்பு, புதிய உதிரிகளுடன் சிக்கலை உருவாக்கலாம்.
• PHP பதிப்பு தேவையை ஆய்வு செய்யவும். உதிரி பக்கத்தில் குறைந்தபட்ச PHP பதிப்பு பொதுவாக குறிப்பிடப்படுகின்றது.
• மாற்று உதிரியை ஆய்வு செய்யவும். நீண்ட காலம் புதுப்பிக்கப்படாத உதிரிகள் பாதுகாப்பு ஆபத்துக்கள் கொண்டிருக்கலாம்.
• Staging சூழலுக்கு அதே பிழையை மீண்டும் உருவாக்கவும். நேர்மறை வலைத்தளத்தில் சோதனை பிழை செய்யாதீர்கள்.
• வளர்த்தவருக்கு பதிவுகளை உடன் ஆதரவு கோரிக்கை அனுப்பவும். வெறும் "வலைத்தளம் இடிந்து போகிறது" என்றால் போதாது.

எடுத்துக்காட்டாக, ஒரு படிவ உதிரி மரண பிழை தருகின்றது மற்றும் பிழை வெறும் PHP 8.3 இல் உருவாகினால், தற்காலிகமாக PHP 8.2 உடன் வலைத்தளத்தை இயக்கலாம், அதே சமயம் உதிரி வளர்த்தவரின் பொருத்தம் புதுப்பிப்பை எதிர்பார்க்கலாம். ஆனால் இந்த தற்காலிக முடிவு பாதுகாப்பு புதுப்பிப்புகளை தடுக்கும் அளவுக்கு நீடிக்கக்கூடாது.

மரண பிழை மீண்டும் ஏற்படாமல் இருக்க முன்னெச்சரிக்கைகள்

வேர்ட்பிரஸ் வலைத்தளங்களில் பிழை ஆபத்தை முற்றிலும் நீக்குவது சாத்தியமில்லை; ஆனால் நல்ல பராமரிப்பு வழிமுறையால் பெரும்பாலும் குறைக்கலாம். குறிப்பாக வருமானம் தரும் நிறுவன வலைத்தளங்களில், புதுப்பிப்பு செயல்முறை சீரான முறையில், கட்டுப்படுத்தப்பட்டதாக இருக்க வேண்டும்.

• Staging ஐப் பயன்படுத்துங்கள்: உதிரி, தீமை மற்றும் PHP புதுப்பிப்புகளை முதலில் சோதனை சூழலில் சோதிக்கவும்.
• தானாகவே புதுப்பிப்புகளை தேர்வாகப் பயன்படுத்துங்கள்: முக்கிய உதிரிகளில் தானாகவே புதுப்பிப்புகள் செயற்கை முறையில் பாதுகாப்பாக இருக்கலாம்.
• காப்பீட்டு அட்டவணையை அதிகரிக்கவும்: அதிக உள்ளடக்கம் அல்லது ஆர்டர்கள் உள்ள வலைத்தளங்களில் தினசரி காப்பீடு போதுமானதாக இருக்க முடியாது.
• உதிரி எண்ணிக்கையைக் குறைக்கவும்: ஒவ்வொரு உதிரியும் கூடுதல் குறியீடு, கூடுதல் பாதுகாப்பு ஆபத்து மற்றும் கூடுதல் பொருந்தாத தேவையைக் குறிக்கிறது.
• புதுப்பிக்கப்படாத உத்திரிகளை அகற்றுங்கள்: 12 மாதங்களுக்கு மேலாக புதுப்பிக்கப்படாத உதிரிகளை கவனமாக மதிப்பீடு செய்ய வேண்டும்.
• SSL மற்றும் பாதுகாப்பு சோதனைகளை அலட்சியமாகக் கொள்ளாதீர்கள்: பாதுகாப்பான இணைப்பு, நிர்வாக குழு மற்றும் பயனர் தகவல்களுக்கு அடிப்படையாகும். SSL சான்றிதழ்
• அலுவலகப் பெயர் மற்றும் DNS அணுகலைப் பிரத்தியேகமாக வைத்திருக்கவும்: முக்கிய தருணங்களில் டொமைன் மற்றும் DNS மேலாண்மைக்கு விரைவான அணுகல் தேவைப்படுகிறது. அமைப்பு விசாரணை

அடுத்த நல்ல நடைமுறையாக புதுப்பிப்பு பதிவேட்டை வைத்திருக்கலாம். எளிய ஆவணத்தில் தேதி, புதுப்பிக்கப்பட்ட உதிரி, பழைய பதிப்பு, புதிய பதிப்பு மற்றும் சோதனை முடிவு எழுதுவது, எதிர்காலத்தில் உருவாகும் பிழைகளின் முதன்மை காரணத்தை கண்டுபிடிக்க எளிதாக்குகிறது. முகவர்களுக்கு, இந்த பதிவுகள், வாடிக்கையாளர் தொடர்பில் வெளிப்படைத்தன்மையை வழங்குகிறது.

நேர்மறை வலைத்தளத்தில் பிழை சீரமைக்கும்போது செய்யக்கூடாதவை

மரண பிழை ஏற்படும் போது சில தலையீடு, சிக்கல்களை தீர்க்கும் பதிலாக அதை மேலும் அதிகரிக்கலாம். குறிப்பாக, தேடுபொறிகளில் விரைவில் காணப்படும் பழைய அறிவுறுத்தல்கள் ஒவ்வொரு வலைத்தளத்திற்கும் பொருந்தாது. கீழ்காணும் தவறுகளைத் தவிர்க்க, தரவுப் போக்கையும் நீண்ட கால இடைவெளியையும் தடுக்கும்.

• காப்பீடு எடுக்காமல் தரவுத்தளத்தை மாற்றாதீர்கள்.
• பிழை தரும் உதிரி அடையை நேரடியாக அழிக்காதீர்கள்; முதலில் மறுபெயரிடுங்கள்.
• நேர்மறை வலைத்தளத்தில் debug பிழைகளை பார்வையாளர்களுக்கு காட்டாதீர்கள்.
• எல்லா உதிரிகளையும் ஒரே நேரத்தில் மீண்டும் செயல்படுத்தாதீர்கள்.
• PHP பதிப்பை அடிக்கடி மாற்றி அடிப்படையில் சோதனை செய்யாதீர்கள்.
• நம்பகமற்ற ஆதாரங்களில் இருந்து உதிரி கோப்புகளை பதிவிறக்காதீர்கள்.
• பிழை செய்தியை பதிவு செய்யாமல் தலையீடு செய்யாதீர்கள்.

சிறந்தது, nullified அல்லது உரிமையற்ற உதிரிகள் மரண பிழை தவிர, பாதுகாப்பு சிக்கல்கள், தீங்கு விளைவிக்கும் குறியீடு மற்றும் தரவுப் போக்கின் ஆபத்தை ஏற்படுத்தும். ஒரு உதிரி பணத்தின் அடிப்படையில் இருந்தால், அதைப் அதிகாரப்பூர்வ உரிமையுடன் மட்டுமே பயன்படுத்த வேண்டும்; புதுப்பிப்பு மற்றும் ஆதரவு வழிமுறைகளை திறந்ததாக வைத்திருக்க வேண்டும்.

எப்போது ஹோஸ்டிங் ஆதரவுக்கு அணுக வேண்டும்?

சில சந்தர்ப்பங்களில் சிக்கல் வெறும் வேர்ட்பிரஸ் குழுவில் தீர்க்க முடியாது. சர்வர் பிழை பதிவுகளுக்கு அணுக முடியாவிட்டால், PHP பதிப்பை மாற்ற முடியாவிட்டால், கோப்பு அனுமதிகள் உடைந்தால் அல்லது வலைத்தளம் முற்றிலும் 500 பிழை தரும்இ என்றால், ஹோஸ்டிங் ஆதரவு செயல்முறை விரைவாக முன்னேற்றமாக்கும். ஆதரவு குழுவிற்கு அணுகும்போது, கீழ்காணும் தகவல்களை தயார் செய்யவும்:

• பிழை தொடங்கிய தேதி மற்றும் சுமார் நேரம்.
• கடைசி செய்யப்பட்ட புதுப்பிப்பு அல்லது நிறுவல் தகவல்.
• திரையில் காணப்படும் பிழை செய்தி.
• இருந்தால் debug.log அல்லது error_log வரிகள்.
• நீங்கள் முயற்சித்த செயல்முறைகள் மற்றும் முடிவுகள்.

இந்த தகவல்கள், ஆதரவு குழுவிற்கு பதிவுகளில் சரியான நேர இடைவெளியைப் பார்ப்பதற்குக் உதவுகிறது. எனவே, பொதுவான கட்டுப்பாட்டுக்கு பதிலாக, நேரடியாக முதன்மை காரணத்தைக் கவனிக்கலாம். Hostragons அடிப்படையில் வேர்ட்பிரஸ் திட்டங்களுக்கு விரைவான கோப்பு மேலாண்மை, PHP பதிப்பு தேர்வு, SSL நிறுவல் மற்றும் ஹோஸ்டிங் ஆதாரம் கண்காணிப்பு போன்ற செயல்களுடன், பிழை தீர்வு செயல்முறை மிகவும் கட்டுப்படுத்தப்பட்ட முறையில் முன்னேறலாம். Hostragons ஆதரவுக் மையம்

குறுக்கமான சுருக்கம் மற்றும் முடிவு

வேர்ட்பிரஸ் மரண பிழை தீர்வு, நீங்கள் சரியான வரிசையில் முன்னேறும் போது சிக்கலாக இருக்க வேண்டியதில்லை. முதலில் காப்பீடு எடுக்கவும், பிழை செய்தியை அல்லது பதிவுகளை ஆய்வு செய்யவும், உதிரிகளை பாதுகாப்பாக முடக்கவும், சிக்கலான உதிரியை தனித்தனியாக சோதிக்கவும். பின்னர் PHP பதிப்பு, நினைவக வரம்பு, உதிரி பொருத்தம் மற்றும் புதுப்பிப்பு வரலாற்றைக் கணக்காய்வு செய்து நிலையான தீர்வு செயல்படுத்தவும்.

உங்கள் வலைத்தளம் அடிக்கடி மரண பிழை தருவதால், புதுப்பிப்புகளில் இடிந்து போகிறதா அல்லது ஆதார வரம்புகளைப் பாதிக்கிறதா எனில், உங்கள் அடிப்படையைப் பார்வையிட நேரம் வந்திருக்கும். Hostragons இல் வேர்ட்பிரஸ் மையமான ஹோஸ்டிங் தீர்வுகளைப் பார்வையிடுவதன் மூலம், மேலாண்மையில், காப்பீட்டுடன் மற்றும் பாதுகாப்பான வேலை சூழலை உருவாக்கலாம். WordPress ஹோஸ்டிங்

அடிக்கடி கேட்கப்படும் கேள்விகள்

வேர்ட்பிரஸ் மரண பிழை என் வலைதளத் தரவுகளை அழிக்குமா?

பொதுவாக இல்லை. மரண பிழை பெரும்பாலும் PHP குறியீட்டின் செயல்பட முடியாமையுடன் தொடர்புடையது மற்றும் உங்கள் உள்ளடக்கங்களை நேரடியாக அழிக்காது. ஆனால் அக்கறையின்றி கோப்புகளை அழித்தால் அல்லது காப்பீடு இல்லாமல் தரவுத்தளத்தை மாற்றினால், தரவுப் போக்கு ஏற்படலாம்.

எந்த உதிரி என் வலைத்தளத்தை இடிந்து போகச் செய்தது என்பதை நான் எப்படி அறிந்துகொள்கிறேன்?

பிழை பதிவில் wp-content/plugins அடைவுக்கு பிறகு காணப்படும் உதிரியின் பெயர் மிகவும் வலுவான குறிக்கோளை தருகிறது. பதிவுகள் இல்லையெனில், அனைத்து உதிரிகளையும் முடக்கி, தனித்தனியாக செயல்படுத்தி பிழை மீண்டும் வந்தால், கடைசி செயல்படுத்திய உதிரியை கண்டுபிடிக்கலாம்.

நிர்வாக குழுவிற்கு அணுக முடியாதால், நான்கு உதிரிகளை எப்படி முடக்குவது?

FTP, SSH அல்லது ஹோஸ்டிங் கோப்பு மேலாளருடன் wp-content/plugins அடையின் பெயரை தற்காலிகமாக மாற்றலாம். இந்த செயல்முறை அனைத்து உதிரிகளை முடக்குகிறது மற்றும் பெரும்பாலான சந்தர்ப்பங்களில் நிர்வாக குழுவிற்கு மீண்டும் அணுகலை வழங்குகிறது.

PHP பதிப்பை மாற்றுவது மரண பிழை தீர்வாகுமா?

சில சமயங்களில் அது தீர்க்கும். பிழை உதிரியின் தற்போதைய PHP பதிப்புடன் பொருந்தாததால் உருவாகினால், சரியான பதிப்பிற்கு மாறுவது தற்காலிக அல்லது நிலையான தீர்வு ஆக இருக்க வாய்ப்பு உள்ளது. இருப்பினும், மிகச் சரியான அணுகுமுறை, உதிரியின் சமீபத்திய மற்றும் பொருத்தமான பதிப்பைப் பயன்படுத்துவதாகும்.

மரண பிழை மீண்டும் ஏற்படாமல் இருக்க என்ன செய்ய வேண்டும்?

விரைவு காப்பீடு எடுக்கவும், புதுப்பிப்புகளை முதலில் staging சூழலில் சோதனை செய்யவும், பயன்படுத்தாத உதிரிகளை அகற்றவும், PHP மற்றும் வேர்ட்பிரஸ் பதிப்புகளை புதுப்பிக்கவும் மற்றும் நம்பகமான ஹோஸ்டிங் அடிப்படையைப் பயன்படுத்தவும்.