WordPress White Screen of Death کی وضاحت

White screen of death دراصل ایک PHP fatal error ہے جو آپ کو نظر نہیں آتی۔ WordPress رینڈرنگ کے بیچ میں ایک ناقابلِ تلافی error سے ٹکرایا، PHP رک گیا، اور چونکہ پروڈکشن سرورز پر error display بند ہوتا ہے، اس لیے صفحہ وجہ بتانے کے بجائے خالی واپس آ گیا۔ اس کا حل تقریباً کبھی بھی اندازوں پر نہیں ہوتا: debug log آن کریں، wp-content/debug.log کھولیں، اور آخری fatal لائن پڑھیں۔ وہ لائن بالکل ٹھیک اُس فائل کا نام بتاتی ہے — تقریباً ہمیشہ کوئی plugin یا theme — اور یہی ایک لائن پوری مرمت ہے۔

اسکرین خالی کیوں ہے

PHP میں ایک سیٹنگ ہوتی ہے جس کا نام display_errors ہے۔ ڈیولپمنٹ مشین پر یہ عموماً آن ہوتی ہے، اس لیے fatal error اسکرین پر ایک stack trace پرنٹ کر دیتی ہے۔ اصل ہوسٹ پر یہ ڈیفالٹ طور پر بند ہوتی ہے، کیونکہ فائل پاتھ اور errors کو وزیٹرز تک لیک کرنا ایک سیکیورٹی مسئلہ ہے۔ چنانچہ جب کوئی چیز fatal error پھینکتی ہے — کسی ایسے function کو کال جو اب موجود نہیں، کوئی class جو لوڈ ہی نہیں ہوئی، کسی plugin اپڈیٹ میں syntax error — تو PHP مر جاتا ہے اور کچھ بھی بھیجتا نہیں۔ آپ کا براؤزر ایک خالی document رینڈر کر دیتا ہے۔ یہی ہے “white screen”۔

WordPress 5.2 سے ایک fatal error handler (WP_Fatal_Error_Handler) موجود ہے جو انہیں پکڑنے کی کوشش کرتا ہے۔ جب یہ کام کرتا ہے تو آپ کو خالی صفحہ نہیں ملتا — آپ کو “There has been a critical error on this website” ملتا ہے، اور ساتھ ہی ایڈمن ایڈریس پر ایک ای میل جاتی ہے جس میں اکثر اصل error اور Recovery Mode کا لنک ہوتا ہے۔ ایک واقعی خالی اسکرین کا عموماً مطلب یہ ہے کہ error اُس handler کے چلنے سے پہلے ہی فائر ہو گئی: کوئی parse/syntax error (جو compile time پر پکڑی جاتی ہے)، کوئی خراب must-use plugin، یا ایکٹو theme کی functions.php میں کوئی fatal۔ بہرحال، وجہ کہیں نہ کہیں لکھی ہوتی ہے۔ آپ کو بس لکھائی آن کرنی ہے۔

اسے ترتیب سے ٹھیک کریں

1. لاگ آن کریں۔ SFTP کے ذریعے wp-config.php ایڈٹ کریں اور یہ کوڈ /* That's all, stop editing! */ والی لائن کے اوپر شامل کریں:

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

WP_DEBUG_DISPLAY کو false رکھنے سے errors پبلک صفحے سے دور رہتی ہیں جبکہ WP_DEBUG_LOG انہیں wp-content/debug.log میں لکھتا ہے۔ ایک تازہ اندراج بنانے کے لیے خراب صفحہ ایک بار ری لوڈ کریں۔

2. آخری fatal پڑھیں۔ wp-content/debug.log کھولیں اور سب سے نیچے دیکھیں:

tail -n 30 wp-content/debug.log

آپ کو اس طرح کی ایک لائن ڈھونڈنی ہے:

[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

پاتھ مجرم کا نام بتاتا ہے: plugins/some-addon۔ یہی آپ کا جواب ہے۔ اگر trace لمبا ہو یا پیغام مبہم ہو (Allowed memory size exhausted، Cannot redeclare، کوئی class نام جسے آپ نہیں پہچانتے)، تو اسے ہمارے error log decoder میں پیسٹ کریں — یہ شور ہٹا دیتا ہے، بتاتا ہے کہ پاتھ کس plugin یا theme کی طرف اشارہ کر رہا ہے، اور سمجھاتا ہے کہ اس مخصوص error type کا کیا مطلب ہے۔

3. نامزد کمپوننٹ کو غیر فعال کریں۔ آپ /wp-admin تک نہیں پہنچ سکتے، اس لیے یہ کام SFTP کے ذریعے کریں۔ متعلقہ plugin کے فولڈر کا نام بدل دیں، مثلاً some-addon → some-addon.off۔ WordPress اُس فولڈر کو لوڈ نہیں کر سکتا جو اسے ملتا ہی نہیں، اس لیے وہ plugin کو غیر فعال کر دیتا ہے اور سائٹ واپس آ جاتی ہے۔ اگر لاگ آپ کے theme کی طرف اشارہ کرے، تو ایکٹو theme فولڈر کا نام بدل کر کسی ڈیفالٹ theme پر چلے جائیں — WordPress کسی بنڈل شدہ twentytwentysomething پر واپس آ جاتا ہے۔

4. اگر لاگ نہ لکھے، تو یا تو wp-content رائٹ ایبل نہیں، یا error سرور لیول پر ہے۔ اس کے بجائے ہوسٹ کا PHP error log چیک کریں:

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

وہی معلومات، مختلف فائل۔ cPanel/Apache اسٹیکس اکثر سائٹ روٹ میں یا خراب ڈائریکٹری میں کوئی error_log چھوڑ دیتے ہیں۔

کیا نہیں کرنا چاہیے

صرف memory limit مت بڑھائیں۔ آن لائن سب سے زیادہ دہرایا جانے والا مشورہ یہی ہے کہ WP_MEMORY_LIMIT کو 256M یا 512M کر دیں۔ یہ WSOD کو صرف تب ٹھیک کرتا ہے جب لاگ واقعی کہے Allowed memory size of N bytes exhausted۔ اگر error Call to undefined function ہے، تو زیادہ memory کچھ نہیں کرتی — آپ نے بے تُکی طرح ایک سیٹنگ بدل دی اور اسکرین اب بھی سفید ہے۔ پہلے لاگ پڑھیں، پھر memory تب بڑھائیں جب memory ہی بیان کردہ مسئلہ ہو۔

اپنا cache صاف کر کے اسے تشخیص مت سمجھیں۔ White screen اُس وقت ہوتی ہے جب PHP کسی بھی HTML کے وجود میں آنے سے پہلے سرور پر مر جاتا ہے۔ کوئی باسی cache ہوا asset خالی document کا سبب نہیں بن سکتا۔ (ایک خراب caching plugin بن سکتا ہے — لیکن لاگ اس کا نام بتا دے گا، اور بات یہی ہے۔)

کور WordPress کو ایڈٹ یا دوبارہ انسٹال مت کریں۔ fatal تقریباً کبھی بھی wp-includes یا wp-admin میں نہیں ہوتی؛ یہ اُس plugin یا theme میں ہوتی ہے جس کی طرف لاگ اشارہ کرتا ہے۔ کور دوبارہ انسٹال کرنا سست، خطرناک ہے، اور ایک ایسی علامت کا علاج کرتا ہے جس کی آپ نے تصدیق ہی نہیں کی۔

تمام plugins کو غیر فعال کر کے انہیں اندھا دھند ایک ایک کر کے دوبارہ فعال مت کریں۔ Bisecting کام کرتا ہے، لیکن یہ سست راستہ ہے۔ لاگ آپ کو ایک ہی قدم میں بالکل درست فولڈر بتا دیتا ہے۔ “سب کچھ بند کر دو” والا طریقہ صرف تب اپنائیں جب کوئی پڑھنے کے قابل error ہو ہی نہیں۔

پروڈکشن میں display_errors آن مت چھوڑیں۔ جب سائٹ واپس آ جائے، تو debug defines ہٹا دیں (یا WP_DEBUG کو دوبارہ false کر دیں)۔ وزیٹرز کو پرنٹ ہونے والی errors آپ کے پاتھ ظاہر کر دیتی ہیں۔

اب بھی پھنسے ہوئے ہیں؟

اگر لاگ کسی plugin کا نام بتائے مگر اسے غیر فعال کرنے سے اسکرین صاف نہ ہو، تو پہلی کے نیچے ایک دوسری fatal موجود ہے — لاگ دوبارہ آن کریں اور نئی آخری لائن پڑھیں؛ fatals تہہ در تہہ جمع ہوتی ہیں۔ اگر پیغام خود ہی دیوار بن جائے، تو اسے error log decoder میں ڈالیں اور اسے error type اور فائل پاتھ آپ کے لیے ترجمہ کرنے دیں۔ White screen صرف اُسی وقت تک ایک معمہ رہتی ہے جب تک لاگ بند ہے۔