"There Has Been a Critical Error on This Website": इसका मतलब क्या है और इसे कैसे ठीक करें

वह मैसेज बताता है कि आपका पेज बनाते समय PHP में fatal error आई, और सफेद खाली स्क्रीन बनने से पहले WordPress ने उसे पकड़ लिया। error असली है, स्पष्ट है और रिकॉर्ड हो चुकी है — WordPress बस उसे ब्राउज़र में छापने से मना कर रहा है, क्योंकि सार्वजनिक पेज पर stack trace दिखाने से हर आने-जाने वाले को फाइल पाथ और कोड दिख जाते हैं।

इसलिए इसका हल कभी अंदाजा लगाकर नहीं निकलता। तरीका यह है: असली error पढ़ें, फिर वही करें जो वह बता रही है।

असल में हो क्या रहा है

WordPress 5.2 से core में एक fatal error handler मौजूद है। जब request के बीच में PHP मर जाता है, तो यह handler आगे आता है, क्रैश के आउटपुट की जगह वह शालीन-सा सामान्य वाक्य रख देता है, और — अगर वह पता लगा पाए कि किस plugin या theme ने यह किया — तो साइट एडमिन को recovery mode का लिंक ईमेल करने की कोशिश करता है।

इसीलिए आपको पुरानी सफेद स्क्रीन की जगह यह दिखता है। यह सुधार है, लेकिन इसका मतलब यह भी है कि डायग्नोस्टिक जानकारी डिफ़ॉल्ट रूप से छिपी रहती है। मैसेज के दो रूप मौजूद हैं:

आपको क्या दिखता है	कहाँ	यह क्या बताता है
”There has been a critical error on this website.”	फ्रंट एंड, लॉग आउट अवस्था में	fatal error हुई, इससे आगे कोई जानकारी नहीं दी गई
वही लाइन और साथ में “Learn more about troubleshooting WordPress”	फ्रंट एंड या wp-admin	वही error, WordPress आपको हैंडबुक पेज दे रहा है
”…Please check your site admin email inbox for instructions.”	फ्रंट एंड	handler को लगा कि उसने recovery ईमेल भेज दिया है

तीसरा रूप ही काम का है। इसका मतलब है कि WordPress ने क्रैश की जिम्मेदारी किसी खास plugin या theme पर डाली और आपको अंदर जाने का रास्ता देने की कोशिश की।

चरण 1: recovery mode का ईमेल देखें

WordPress recovery लिंक साइट एडमिन ईमेल पते पर भेजता है — वही जो Settings, General में दर्ज है — जो अक्सर वह पता नहीं होता जिससे आप लॉगिन करते हैं। उस इनबॉक्स को देखें, और स्पैम भी देखें।

ईमेल में एक लंबा लिंक होता है जो कुछ इस तरह खत्म होता है: ?action=enter_recovery_mode। उसे खोलने पर आप recovery mode में wp-admin में लॉगिन हो जाते हैं, जहाँ गड़बड़ करने वाला plugin या theme रोक दिया गया होता है और ऊपर लाल नोटिस में उसका नाम दिखता है। वहाँ से आप उसे सामान्य तरीके से निष्क्रिय कर सकते हैं।

दो बातें साफ-साफ समझ लें। पहली, यह ईमेल उसी PHP प्रोसेस से बनता है जो अभी क्रैश हुआ है, और वह भी ऐसे होस्ट पर जहाँ शायद मेल भेजने का कोई इंतजाम ही न हो — ईमेल न आना आम बात है, और उसका न आना error के बारे में कुछ नहीं बताता। दूसरी, recovery लिंक की अवधि खत्म हो जाती है (डिफ़ॉल्ट रूप से लगभग एक दिन), इसलिए इनबॉक्स में पड़ा पुराना ईमेल शायद अब काम ही न करे; साइट दोबारा लोड करके नया क्रैश करवाएँ और नए ईमेल का इंतजार करें।

अगर आप चाहते हैं कि ईमेल वहाँ जाए जहाँ आप सचमुच पढ़ते हैं, तो wp-config.php में इसे साफ तौर पर सेट करें:

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

चरण 2: असली error पढ़ें

यही वह कदम है जो टूटी हुई साइट को पाँच मिनट के काम में बदल देता है। wp-config.php में, “अब आगे एडिट न करें” वाली लाइन के ऊपर, ये लाइनें जोड़ें:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY को false रखना मायने रखता है — इससे error ब्राउज़र में नहीं दिखती लेकिन डिस्क पर लिखी जाती रहती है, यानी डिबग करते समय आप विजिटर्स के सामने पाथ नहीं खोल रहे।

टूटे हुए पेज को एक बार रीलोड करें, फिर wp-content/debug.log खोलें। आखिरी एंट्री कुछ ऐसी दिखेगी:

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

फाइल पाथ ही जवाब है। अगर वह wp-content/plugins/ की तरफ इशारा करता है, तो वही plugin वजह है। अगर वह wp-content/themes/ की तरफ जाता है, तो theme वजह है — और अक्सर वह कोड जो हाल ही में functions.php में पेस्ट किया गया था।

अगर debug.log दिखे ही नहीं, तो हो सकता है डायरेक्टरी में लिखने की अनुमति न हो, या किसी सिक्योरिटी plugin ने लॉगिंग कहीं और भेज दी हो। ऐसे में अपने होस्ट के PHP error log पर लौटें — ज्यादातर कंट्रोल पैनल में “Error Log” या “Logs” सेक्शन होता है, और वही fatal error वहाँ टाइमस्टैम्प के साथ मिलेगी।

उस एंट्री को WordPress error log decoder में पेस्ट करें ताकि PHP की भाषा का व्यावहारिक मतलब और यह पता चले कि सबसे पहले कौन-सी फाइल देखनी है।

काम पूरा होते ही ये debug लाइनें हटा दें। प्रोडक्शन में WP_DEBUG चालू छोड़ना डिस्क भर देता है, और अगर कभी WP_DEBUG_DISPLAY वापस चालू हो गया तो सर्वर के पाथ सार्वजनिक रूप से छप जाएँगे।

चरण 3: wp-admin में वापस पहुँचें

अगर wp-admin भी बंद है और कोई recovery ईमेल नहीं आया, तो फाइल सिस्टम के स्तर पर हर plugin बंद कर दें। SFTP (या अपने होस्ट के फाइल मैनेजर) से जुड़ें और एक फोल्डर का नाम बदलें:

mv wp-content/plugins wp-content/plugins-off

WordPress को plugins मिलते ही नहीं, इसलिए वह सबको निष्क्रिय कर देता है और एडमिन एक्सेस लगभग हमेशा लौट आता है। फिर:

1. फोल्डर का नाम वापस plugins कर दें। सब कुछ निष्क्रिय ही रहेगा — WordPress ने उन्हें inactive दर्ज कर लिया है।
2. एक-एक करके plugins चालू करें और हर बार फ्रंट एंड लोड करके देखें।
3. जो plugin error वापस लाए, वही असली वजह है।

अगर सारे plugins बंद होने पर भी साइट टूटी हुई है, तो शक theme पर जाता है। wp-content/themes/ में सक्रिय theme के फोल्डर का नाम बदल दें; अगर कोई डिफ़ॉल्ट theme इंस्टॉल है तो WordPress उसी पर लौट आएगा।

तीन वजहें जो जान लेनी चाहिए

कोई plugin या theme अपडेट जो fatal हो जाता है। सबसे आम वजह। log सीधे फाइल का नाम बताता है। उस एक plugin को उसके पिछले वर्जन पर लौटाएँ, या उसे निष्क्रिय रहने दें और log की लाइन के साथ डेवलपर से संपर्क करें।

PHP वर्जन का मेल न खाना। होस्ट तय समय पर PHP अपग्रेड करते हैं, कभी-कभी ज्यादा चेतावनी दिए बिना। पुराने PHP के लिए लिखा कोड नए वर्जन पर पार्स होना ही बंद कर सकता है। पहचान यह है कि आपकी तरफ से कुछ नहीं बदला और सब कुछ एक साथ टूट गया। होस्टिंग पैनल में PHP को एक माइनर वर्जन पीछे ले जाना जायज डायग्नोसिस है — लेकिन इसे समय खरीदना समझें, इलाज नहीं। पुराने PHP वर्जन को सिक्योरिटी पैच मिलने बंद हो जाते हैं।

मेमोरी खत्म हो जाना। log कहता है “Allowed memory size of X bytes exhausted”। ऐसे में wp-config.php में लिमिट बढ़ाना ठीक है:

define( 'WP_MEMORY_LIMIT', '256M' );

लेकिन ईमानदारी से समझें कि इससे होता क्या है: यह छत हटा देता है, यह ठीक नहीं करता कि एक पेज बनाने में 256MB खर्च किसने किया। अगर लिमिट बार-बार बढ़ानी पड़ रही है, तो असली समस्या कुछ और है — आमतौर पर कोई import, कोई page builder, या खराब तरीके से लिखी गई कोई query।

वह सलाह जिसे आराम से नजरअंदाज किया जा सकता है

“बस memory limit बढ़ा दो।” यह तभी काम की है जब log सचमुच कहे कि मेमोरी खत्म हुई। वरना इससे कुछ नहीं बदलता और यह छिपा देती है कि आपने error पढ़ी ही नहीं।

“WordPress core दोबारा इंस्टॉल कर दो।” core फाइलें शायद ही कभी वजह होती हैं, और उन्हें बदलने में वह समय बर्बाद होता है जिसमें आप log की एक लाइन पढ़ सकते थे।

“fatal error handler बंद कर दो।” इसे बंद करने के लिए एक constant मौजूद है, और नतीजा यह होता है कि पकड़ी गई error की जगह कच्ची error आपकी सार्वजनिक साइट पर छप जाती है। इससे विजिटर्स को फाइल पाथ दिख जाते हैं। इसके बजाय WP_DEBUG_LOG का इस्तेमाल करें और WP_DEBUG_DISPLAY बंद रखें — जानकारी वही, खतरा कोई नहीं।

“अपना cache क्लियर करो।” fatal error PHP में तब होती है जब कोई cache plugin कुछ परोस भी नहीं पाता। अगर error वाले पेज की cached कॉपी परोसी जा रही है, तो cache क्लियर करना वजह ठीक करने के बाद मदद करता है — उसकी जगह कभी नहीं।

फिर भी अटके हुए हैं?

अगर log wp-content के बजाय किसी core फाइल की तरफ इशारा करता है, तो ज्यादा संभावना यह है कि पहले लोड हुए किसी plugin ने वह स्थिति बिगाड़ दी जिस पर core निर्भर है — न कि core खराब हो गया है। फोल्डर का नाम बदलकर सब कुछ बंद करें, पुष्टि करें कि साइट साफ लोड हो रही है, फिर एक-एक करके plugins वापस लाएँ — error लौटने से ठीक पहले आपने जो आखिरी plugin चालू किया, वही रिपोर्ट करने लायक है, log की लाइन के साथ।