"There has been a critical error on this website" کا مطلب کیا ہے اور اسے کیسے ٹھیک کریں

یہ پیغام بتاتا ہے کہ آپ کا صفحہ بناتے ہوئے PHP کو ایک فیٹل ایرر پیش آیا، اور WordPress نے اسے خالی سفید سکرین بننے سے پہلے پکڑ لیا۔ خرابی حقیقی ہے، مخصوص ہے اور ریکارڈ بھی ہو چکی ہے — WordPress بس اسے براؤزر میں چھاپنے سے انکار کر رہا ہے، کیونکہ عوامی صفحے پر اسٹیک ٹریس ہر آنے والے کے سامنے فائل پاتھ اور کوڈ کھول دیتا ہے۔

اس لیے اس کا حل کبھی اندازوں سے نہیں نکلتا۔ طریقہ ایک ہی ہے: اصل خرابی پڑھیں، پھر جو وہ کہہ رہی ہے اس پر عمل کریں۔

اصل میں ہو کیا رہا ہے

WordPress 5.2 سے کور میں ایک فیٹل ایرر ہینڈلر شامل ہے۔ جب PHP درخواست کے بیچ میں مر جاتا ہے تو یہ ہینڈلر آگے بڑھ کر کریش کے آؤٹ پٹ کی جگہ وہ شائستہ سا عمومی جملہ رکھ دیتا ہے، اور اگر وہ یہ اندازہ لگا سکے کہ قصور کس پلگ ان یا تھیم کا ہے تو سائٹ ایڈمن کو ریکوری موڈ کے لنک کے ساتھ ای میل بھیجنے کی کوشش کرتا ہے۔

اسی لیے آپ کو پرانی وائٹ سکرین آف ڈیتھ کے بجائے یہ نظر آتا ہے۔ یہ بہتری تو ہے، مگر اس کا مطلب یہ بھی ہے کہ تشخیصی معلومات پہلے سے چھپی ہوئی ہیں۔ اس پیغام کی دو صورتیں ہیں:

آپ کو کیا نظر آتا ہے	کہاں	یہ کیا بتاتا ہے
”There has been a critical error on this website.”	فرنٹ اینڈ، لاگ آؤٹ حالت میں	فیٹل ایرر ہوا ہے، مزید کوئی تفصیل ظاہر نہیں کی گئی
وہی جملہ اور ساتھ “Learn more about troubleshooting WordPress”	فرنٹ اینڈ یا wp-admin	وہی خرابی، WordPress آپ کو ہینڈ بک کا صفحہ پیش کر رہا ہے
”…Please check your site admin email inbox for instructions.”	فرنٹ اینڈ	ہینڈلر سمجھتا ہے کہ اس نے ریکوری ای میل بھیج دیا ہے

تیسری صورت سب سے کارآمد ہے۔ اس کا مطلب ہے کہ WordPress نے کریش کو کسی مخصوص پلگ ان یا تھیم سے جوڑ لیا اور آپ کو اندر جانے کا راستہ دینے کی کوشش کی۔

پہلا مرحلہ: ریکوری موڈ ای میل دیکھیں

WordPress ریکوری لنک سائٹ ایڈمن ای میل پتے پر بھیجتا ہے — یعنی وہی جو Settings، General میں درج ہے — اور یہ اکثر وہ پتہ نہیں ہوتا جس سے آپ لاگ اِن کرتے ہیں۔ وہ اِن باکس دیکھیں، اور اسپَیم بھی۔

ای میل میں ایک لمبا لنک ہوتا ہے جو کچھ اس طرح ختم ہوتا ہے: ?action=enter_recovery_mode۔ اسے کھولنے پر آپ ریکوری موڈ میں wp-admin کے اندر لاگ اِن ہو جاتے ہیں، جہاں قصوروار پلگ ان یا تھیم روک دیا گیا ہوتا ہے اور اوپر سرخ نوٹس میں نشان زد ہوتا ہے۔ وہاں سے آپ اسے معمول کے مطابق غیر فعال کر سکتے ہیں۔

دو باتیں صاف کہہ دینی چاہئیں۔ پہلی، یہ ای میل اسی PHP پروسیس نے بنایا ہے جو ابھی کریش ہوا ہے، ایسے ہوسٹ پر جہاں شاید میل بھیجنے کا کوئی کام کرنے والا نظام موجود ہی نہ ہو — ای میل کا نہ پہنچنا عام بات ہے، اور اس کی غیر موجودگی خرابی کے بارے میں کچھ نہیں بتاتی۔ دوسری، ریکوری لنک کی مدت ختم ہو جاتی ہے (پہلے سے طے شدہ طور پر تقریباً ایک دن)، اس لیے اِن باکس میں پڑا پرانا ای میل شاید اب کام ہی نہ کرے؛ سائٹ دوبارہ لوڈ کر کے تازہ کریش کروائیں اور نئے ای میل کا انتظار کریں۔

اگر آپ چاہتے ہیں کہ ای میل وہاں جائے جہاں آپ واقعی پڑھتے ہیں تو اسے wp-config.php میں صراحتاً طے کر دیں:

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

دوسرا مرحلہ: اصل خرابی پڑھیں

یہی وہ مرحلہ ہے جو ٹوٹی ہوئی سائٹ کو پانچ منٹ کے کام میں بدل دیتا ہے۔ 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 ہونا اہم ہے — یہ خرابی کو براؤزر سے دور رکھتا ہے مگر ڈسک پر لکھنا جاری رکھتا ہے، یعنی ڈی بگ کرتے ہوئے آپ آنے والوں کے سامنے پاتھ نہیں کھول رہے۔

ٹوٹا ہوا صفحہ ایک بار دوبارہ لوڈ کریں، پھر 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/ کے اندر اشارہ کرتا ہے تو وجہ وہی پلگ ان ہے۔ اگر wp-content/themes/ کے اندر جاتا ہے تو تھیم ذمہ دار ہے — اور اکثر یہ وہ کوڈ ہوتا ہے جو حال ہی میں functions.php میں پیسٹ کیا گیا ہو۔

اگر debug.log نظر ہی نہ آئے تو ممکن ہے ڈائریکٹری قابلِ تحریر نہ ہو، یا کسی سیکیورٹی پلگ ان نے لاگنگ کہیں اور منتقل کر دی ہو۔ ایسی صورت میں اپنے ہوسٹ کی PHP ایرر لاگ پر جائیں — زیادہ تر کنٹرول پینلز میں “Error Log” یا “Logs” کا حصہ ہوتا ہے، اور وہی فیٹل ایرر وقت کی مہر کے ساتھ وہاں موجود ہو گا۔

اندراج کو WordPress ایرر لاگ ڈی کوڈر میں پیسٹ کریں تاکہ PHP کی زبان کا عملی مطلب سامنے آئے اور یہ پتہ چلے کہ سب سے پہلے کون سی فائل دیکھنی ہے۔

کام مکمل ہونے پر یہ ڈی بگ لائنیں ہٹا دیں۔ پروڈکشن میں WP_DEBUG کھلا چھوڑنا ڈسک بھر دیتا ہے، اور اگر کبھی WP_DEBUG_DISPLAY واپس آن ہو گیا تو سرور کے پاتھ عوامی طور پر چھپنے لگیں گے۔

تیسرا مرحلہ: دوبارہ wp-admin میں داخل ہوں

اگر wp-admin بھی مر چکا ہے اور کوئی ریکوری ای میل نہیں آیا تو فائل سسٹم کی سطح پر تمام پلگ ان بند کر دیں۔ SFTP (یا اپنے ہوسٹ کے فائل مینیجر) سے جڑیں اور ایک فولڈر کا نام بدل دیں:

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

WordPress کو پلگ ان ملتے ہی نہیں، اس لیے وہ سب کو غیر فعال کر دیتا ہے اور ایڈمن تک رسائی تقریباً ہمیشہ واپس آ جاتی ہے۔ اس کے بعد:

1. فولڈر کا نام واپس plugins کر دیں۔ سب کچھ غیر فعال ہی رہے گا — WordPress نے انہیں غیر فعال ریکارڈ کر لیا تھا۔
2. ایک ایک کر کے پلگ ان فعال کریں اور ہر بار فرنٹ اینڈ لوڈ کریں۔
3. جس پر خرابی واپس آ جائے، وہی آپ کا مجرم ہے۔

اگر تمام پلگ ان بند ہونے کے باوجود سائٹ ٹوٹی رہے تو شک تھیم پر جاتا ہے۔ wp-content/themes/ میں فعال تھیم کے فولڈر کا نام بدل دیں؛ اگر کوئی ڈیفالٹ تھیم انسٹال ہوا تو WordPress اسی پر واپس آ جائے گا۔

تین وجوہات جو جاننا ضروری ہیں

ایسا پلگ ان یا تھیم اپ ڈیٹ جو فیٹل ہو جائے۔ یہی سب سے عام ہے۔ لاگ سیدھا فائل کا نام بتا دیتی ہے۔ اُس ایک پلگ ان کو پچھلے ورژن پر واپس لے جائیں، یا اسے غیر فعال چھوڑ کر لاگ کی لائن کے ساتھ ڈویلپر سے رابطہ کریں۔

PHP ورژن کا میل نہ کھانا۔ ہوسٹس ایک شیڈول کے مطابق PHP اپ گریڈ کرتے ہیں، کبھی کبھی زیادہ اطلاع دیے بغیر۔ پرانے PHP کے لیے لکھا گیا کوڈ نئے ورژن پر پارس ہی ہونا بند کر سکتا ہے۔ پہچان یہ ہے کہ آپ کی طرف سے کچھ نہیں بدلا اور سب کچھ ایک ساتھ ٹوٹ گیا۔ ہوسٹنگ پینل میں PHP کو ایک مائنر ورژن پیچھے لے جانا درست تشخیصی قدم ہے — مگر اسے وقت خریدنا سمجھیں، حل نہیں۔ پرانے PHP ورژنز کو سیکیورٹی پیچ ملنا بند ہو جاتے ہیں۔

میموری ختم ہو جانا۔ لاگ کہتی ہے “Allowed memory size of X bytes exhausted”۔ ایسے میں wp-config.php میں حد بڑھانا مناسب ہے:

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

مگر صاف بات یہ ہے کہ اس سے صرف چھت ہٹتی ہے؛ یہ اُس چیز کو ٹھیک نہیں کرتا جس نے ایک صفحہ بنانے میں 256MB کھا لیے۔ اگر حد بار بار بڑھانی پڑ رہی ہے تو اصل مسئلہ کچھ اور ہے — عام طور پر کوئی امپورٹ، پیج بلڈر، یا خراب لکھی گئی کوئری۔

وہ مشورے جنہیں بے فکر ہو کر نظرانداز کر دیں

“بس میموری لِمٹ بڑھا دیں۔” یہ صرف اُس وقت متعلقہ ہے جب لاگ واقعی میموری ختم ہونے کی بات کرے۔ ورنہ اس سے کچھ نہیں بدلتا اور یہ حقیقت چھپ جاتی ہے کہ آپ نے خرابی پڑھی ہی نہیں۔

“WordPress کور دوبارہ انسٹال کر دیں۔” کور فائلیں شاذ و نادر ہی وجہ ہوتی ہیں، اور انہیں بدلنے میں وہ وقت ضائع ہوتا ہے جو لاگ کی ایک لائن پڑھنے پر لگ سکتا تھا۔

“فیٹل ایرر ہینڈلر بند کر دیں۔” اسے بند کرنے کے لیے ایک کونسٹنٹ موجود ہے، اور نتیجہ یہ نکلتا ہے کہ پکڑی ہوئی خرابی کے بجائے خام خرابی آپ کی عوامی سائٹ پر چھپنے لگتی ہے۔ اس سے آنے والوں کے سامنے فائل پاتھ کھل جاتے ہیں۔ اس کے بجائے WP_DEBUG_LOG استعمال کریں اور WP_DEBUG_DISPLAY بند رکھیں — وہی معلومات، بغیر کسی نمائش کے۔

“کیشے صاف کر دیں۔” فیٹل ایرر PHP میں اُس وقت ہوتا ہے جب کیشے پلگ ان کچھ پیش کر بھی نہیں سکتا۔ اگر ایرر والے صفحے کی کیشے شدہ نقل پیش ہو رہی ہے تو صفائی وجہ ٹھیک کرنے کے بعد مدد دیتی ہے — اس کی جگہ کبھی نہیں۔

اب بھی مسئلہ حل نہ ہو؟

اگر لاگ wp-content کے بجائے کسی کور فائل کی طرف اشارہ کرے تو زیادہ ممکنہ وضاحت یہ ہے کہ پہلے لوڈ ہونے والے کسی پلگ ان نے وہ حالت خراب کر دی جس پر کور انحصار کرتا ہے، نہ کہ کور خود خراب ہے۔ فولڈر کا نام بدل کر سب کچھ بند کریں، تصدیق کریں کہ سائٹ صاف لوڈ ہوتی ہے، پھر ایک ایک کر کے پلگ ان واپس لائیں — خرابی لوٹنے سے پہلے آپ نے جو آخری پلگ ان فعال کیا، اسی کی رپورٹ لاگ کی لائن کے ساتھ کریں۔