WordPress White Screen of Death, समझाया गया

White screen of death एक PHP fatal error है जो आपको दिखाई नहीं देता। WordPress render के बीच में एक ऐसी error से टकराया जिससे उबरना नामुमकिन था, PHP रुक गया, और चूंकि production servers पर error display बंद रहता है, इसलिए page ने वजह छापने के बजाय खाली लौट आया। इसका fix लगभग कभी अंदाज़े का काम नहीं होता: debug log चालू करें, wp-content/debug.log खोलें, और आखिरी fatal line पढ़ें। यह ठीक-ठीक बता देती है कि कौन-सी file गड़बड़ है — लगभग हमेशा कोई plugin या theme — और वही एक line पूरी मरम्मत है।

screen खाली क्यों है

PHP में एक setting होती है जिसका नाम है display_errors। development machine पर यह आमतौर पर चालू रहती है, इसलिए fatal error screen पर एक stack trace छाप देता है। असली host पर यह by default बंद रहती है, क्योंकि file paths और errors को visitors के सामने लीक करना एक security समस्या है। तो जब कोई चीज़ fatal error फेंकती है — किसी ऐसे function को call करना जो अब मौजूद ही नहीं, कोई class जो load नहीं हुई, किसी plugin update में syntax error — तो PHP मर जाता है और कुछ नहीं भेजता। आपका browser एक खाली document render करता है। यही “white screen” है।

WordPress 5.2 से एक fatal error handler (WP_Fatal_Error_Handler) है जो इन्हें पकड़ने की कोशिश करता है। जब यह काम करता है, तो आपको खाली page नहीं मिलता — आपको मिलता है “There has been a critical error on this website,” और साथ में admin address पर एक email जिसमें अक्सर असली error और Recovery Mode का link होता है। सचमुच खाली screen का आमतौर पर मतलब है कि error उस handler के चलने से पहले ही फायर हो गई: कोई parse/syntax error (जो compile time पर पकड़ी जाती है), कोई टूटा हुआ must-use plugin, या active theme की functions.php में कोई fatal। जो भी हो, वजह कहीं न कहीं लिख दी गई है। आपको बस लिखने वाली सुविधा चालू करनी है।

इसे क्रम से ठीक करें

1. log चालू करें। SFTP के ज़रिए wp-config.php edit करें और /* That's all, stop editing! */ line के ऊपर यह जोड़ें:

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

WP_DEBUG_DISPLAY को false रखने से errors public page से बाहर रहती हैं, जबकि WP_DEBUG_LOG उन्हें wp-content/debug.log में लिख देता है। एक ताज़ा entry बनाने के लिए टूटे हुए page को एक बार reload करें।

2. आखिरी fatal पढ़ें। wp-content/debug.log खोलें और सबसे नीचे देखें:

tail -n 30 wp-content/debug.log

आप इस तरह की एक line ढूंढ रहे हैं:

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

path ही गुनहगार का नाम बता देता है: plugins/some-addon। यही आपका जवाब है। अगर trace लंबा है या message पहेली जैसा है (Allowed memory size exhausted, Cannot redeclare, कोई class नाम जिसे आप नहीं पहचानते), तो उसे हमारे error log decoder में paste करें — यह शोर हटा देता है, बताता है कि path किस plugin या theme की तरफ इशारा कर रहा है, और यह भी समझाता है कि उस खास error type का मतलब क्या है।

3. जिस component का नाम आया, उसे deactivate करें। आप /wp-admin तक पहुंच नहीं सकते, इसलिए इसे SFTP के ज़रिए करें। गड़बड़ करने वाले plugin की folder का नाम बदल दें, जैसे some-addon → some-addon.off। WordPress उस folder को load नहीं कर सकता जो उसे मिले ही नहीं, इसलिए वह plugin deactivate हो जाता है और site वापस आ जाती है। अगर log आपकी theme की तरफ इशारा करता है, तो active theme folder का नाम बदलकर किसी default theme पर स्विच करें — WordPress एक bundled twentytwentysomething पर fallback कर जाता है।

4. अगर log लिख ही नहीं रहा, तो या तो wp-content writable नहीं है, या error server level पर है। इसके बजाय host का PHP error log देखें:

find . -name "error_log" -newermt "-1 hour"

वही जानकारी, अलग file में। cPanel/Apache stacks अक्सर site root में या fail होने वाली directory में एक error_log छोड़ देते हैं।

क्या नहीं करना चाहिए

बस memory limit मत बढ़ाइए। online सबसे ज़्यादा दोहराई जाने वाली सलाह यही है कि WP_MEMORY_LIMIT को 256M या 512M कर दो। यह WSOD को तभी ठीक करता है जब log सचमुच कहे Allowed memory size of N bytes exhausted। अगर error Call to undefined function है, तो ज़्यादा memory कुछ नहीं करती — आपने बेतरतीब ढंग से एक setting बदल दी और screen अब भी white है। पहले log पढ़िए, फिर memory तभी बढ़ाइए जब बताई गई समस्या memory ही हो।

cache clear करके उसे diagnosis मत समझिए। white screen तब बनती है जब कोई भी HTML बनने से पहले ही server पर PHP मर जाता है। कोई बासी cached asset खाली document का कारण नहीं बन सकता। (एक टूटा हुआ caching plugin बन सकता है — पर log उसका नाम बता देगा, और यही तो पूरा मुद्दा है।)

core WordPress को edit या reinstall मत कीजिए। fatal लगभग कभी wp-includes या wp-admin में नहीं होती; यह उसी plugin या theme में होती है जिसकी तरफ log इशारा करता है। core को reinstall करना धीमा है, जोखिम भरा है, और एक ऐसे लक्षण का इलाज करता है जिसकी आपने पुष्टि ही नहीं की।

सारे plugins को बंद करके फिर एक-एक करके आंख मूंदकर चालू मत कीजिए। bisecting काम करता है, पर यह धीमा रास्ता है। log एक ही कदम में ठीक-ठीक folder बता देता है। “सब कुछ बंद कर दो” वाला तरीका तभी अपनाइए जब कोई पढ़ने लायक error बिल्कुल न हो।

production में display_errors को चालू मत छोड़िए। एक बार site वापस आ जाए, तो debug defines हटा दें (या WP_DEBUG को वापस false कर दें)। visitors के सामने छपने वाली errors आपके paths उजागर कर देती हैं।

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

अगर log किसी plugin का नाम बताता है पर उसे disable करने से screen साफ़ नहीं होती, तो पहली fatal के नीचे एक दूसरी fatal है — log को वापस चालू करें और नई आखिरी line पढ़ें; fatals एक के ऊपर एक जमती हैं। अगर message खुद ही दीवार बन गया है, तो उसे error log decoder में डाल दें और उसे error type और file path आपके लिए अनुवाद करने दें। white screen तभी तक रहस्य बनी रहती है जब तक log बंद रहता है।