"حدث خطأ فادح في هذا الموقع": ماذا تعني الرسالة وكيف تعالجها

تلك الرسالة تعني أن PHP اصطدم بخطأ فادح أثناء بناء صفحتك، وأن ووردبريس التقطه قبل أن يتحول إلى شاشة بيضاء فارغة. الخطأ حقيقي ومحدد ومسجَّل — ووردبريس فقط يرفض طباعته في المتصفح، لأن عرض تتبع الاستدعاءات على صفحة عامة يكشف مسارات الملفات والكود لكل من يزور الموقع.

لذلك فالحل ليس تخميناً أبداً. الحل هو: اقرأ الخطأ الحقيقي، ثم تصرّف بناءً على ما يقوله.

ما الذي يحدث فعلياً

منذ الإصدار 5.2 صار في نواة ووردبريس معالج مدمج للأخطاء الفادحة. فعندما يتوقف PHP في منتصف الطلب، يتدخل هذا المعالج ويستبدل مخرجات الانهيار بالجملة العامة المهذبة، ثم — إن استطاع تحديد الإضافة أو القالب المتسبب — يحاول إرسال بريد إلى مدير الموقع يحوي رابطاً للدخول إلى وضع الاسترداد.

لهذا ترى هذه الرسالة بدلاً من شاشة الموت البيضاء القديمة. هذا تحسّن، لكنه يعني أيضاً أن المعلومات التشخيصية مخفية افتراضياً. وللرسالة صيغتان:

ما تراه	أين	ما يخبرك به
”حدث خطأ فادح في هذا الموقع.”	الواجهة الأمامية، وأنت غير مسجل الدخول	وقع خطأ فادح، دون كشف أي تفاصيل إضافية
السطر نفسه مع “تعرّف على المزيد حول استكشاف أخطاء ووردبريس”	الواجهة الأمامية أو wp-admin	الخطأ نفسه، وووردبريس يعرض عليك صفحة الدليل
”…يرجى مراجعة بريد مدير الموقع للحصول على التعليمات.”	الواجهة الأمامية	اعتقد المعالج أنه أرسل بريد الاسترداد

الصيغة الثالثة هي المفيدة. فهي تعني أن ووردبريس نسب الانهيار إلى إضافة أو قالب بعينه وحاول أن يمنحك طريقاً للدخول.

الخطوة الأولى: افحص بريد وضع الاسترداد

يرسل ووردبريس رابط الاسترداد إلى عنوان بريد مدير الموقع — العنوان الموجود في الإعدادات ← عام — وهو في الغالب ليس العنوان الذي تسجل به الدخول. راجع ذلك الصندوق، وراجع مجلد الرسائل غير المرغوبة.

يحتوي البريد على رابط طويل ينتهي بشيء مثل ?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”، وستجد الخطأ الفادح نفسه هناك مع طابع زمني.

الصق السطر في مفكك سجل أخطاء ووردبريس ليترجم صياغة PHP إلى معناها العملي ويحدد لك أي ملف تفتحه أولاً.

احذف أسطر التتبع هذه عندما تنتهي. فترك WP_DEBUG مفعّلاً على موقع حي يملأ القرص، وإذا أُعيد WP_DEBUG_DISPLAY إلى وضع التشغيل يوماً ما، فسيطبع مسارات الخادم علناً.

الخطوة الثالثة: استعد الدخول إلى wp-admin

إذا كانت لوحة wp-admin معطلة أيضاً ولم يصل بريد استرداد، عطّل كل الإضافات من مستوى نظام الملفات. اتصل عبر SFTP (أو مدير الملفات لدى مضيفك) وأعد تسمية مجلد واحد:

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

لن يجد ووردبريس الإضافات، فيعطّلها جميعاً، ويعود الوصول إلى لوحة التحكم في أغلب الأحيان. بعدها:

1. أعد تسمية المجلد إلى plugins. ستبقى كل الإضافات معطلة — لأن ووردبريس سجّلها على أنها غير نشطة.
2. فعّل الإضافات واحدة تلو الأخرى، مع تحميل الواجهة الأمامية بعد كل واحدة.
3. الإضافة التي يعود الخطأ معها هي المتسببة.

وإذا بقي الموقع معطلاً مع تعطيل كل الإضافات، فالقالب هو المشتبه به. أعد تسمية مجلد القالب النشط داخل wp-content/themes/ وسيرجع ووردبريس إلى قالب افتراضي إن كان مثبتاً.

الأسباب الثلاثة التي تستحق أن تعرفها

تحديث إضافة أو قالب ينهار. وهو الأكثر شيوعاً بفارق كبير. السجل يذكر الملف مباشرةً. أرجع تلك الإضافة وحدها إلى إصدارها السابق، أو اتركها معطلة وتواصل مع المطوّر ومعك سطر السجل.

عدم توافق إصدار PHP. تُرقّي شركات الاستضافة PHP وفق جدول زمني، وأحياناً دون تنبيه كافٍ. والكود المكتوب لإصدارات أقدم قد يتوقف عن العمل كلياً على إصدار أحدث. العلامة الفارقة أن شيئاً لم يتغير من جهتك ومع ذلك تعطل كل شيء دفعة واحدة. وإرجاع PHP إصداراً فرعياً واحداً من لوحة الاستضافة تشخيص مشروع — لكن اعتبره شراءً للوقت لا حلاً. فالإصدارات القديمة من PHP تتوقف عن تلقي التحديثات الأمنية.

نفاد الذاكرة. يقول السجل حينها “Allowed memory size of X bytes exhausted”. ورفع الحد في wp-config.php تصرف منطقي:

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

لكن كن صريحاً بشأن ما يفعله ذلك: هو يرفع السقف، لكنه لا يعالج ما الذي استهلك 256 ميجابايت لعرض صفحة واحدة. وإذا استمر الحد في الحاجة إلى الرفع، فهناك شيء آخر — عادةً عملية استيراد، أو منشئ صفحات، أو استعلام مكتوب بسوء — هو المشكلة الحقيقية.

نصائح يمكنك تجاهلها بأمان

“فقط ارفع حد الذاكرة.” لا معنى لها إلا إذا قال السجل فعلاً إن الذاكرة نفدت. وإلا فهي لا تغير شيئاً وتخفي حقيقة أنك لم تقرأ الخطأ أصلاً.

“أعد تثبيت نواة ووردبريس.” نادراً ما تكون ملفات النواة هي السبب، واستبدالها يهدر وقتاً كان يكفي لقراءة سطر واحد من السجل.

“عطّل معالج الأخطاء الفادحة.” يوجد ثابت لتعطيله، والنتيجة أن الخطأ الخام يُطبع على موقعك العام بدل أن يُلتقط. وهذا يكشف مسارات الملفات للزوار. استخدم WP_DEBUG_LOG مع تعطيل WP_DEBUG_DISPLAY بدلاً من ذلك — المعلومات نفسها، دون أي انكشاف.

“امسح ذاكرة التخزين المؤقت.” الخطأ الفادح يقع في PHP قبل أن تتمكن إضافة التخزين المؤقت من تقديم أي شيء. وإذا كانت نسخة مخزّنة من صفحة الخطأ هي التي تُقدَّم، فالمسح يفيد بعد معالجة السبب — لا بديلاً عنها.

ما زلت عالقاً؟

إذا كان السجل يشير إلى ملف في النواة بدلاً من شيء داخل wp-content، فالتفسير الأرجح هو إضافة حُمّلت قبله وأفسدت الحالة التي تعتمد عليها النواة، لا أن ملفات النواة تالفة. عطّل كل شيء بإعادة تسمية المجلد، وتأكد أن الموقع يفتح نظيفاً، ثم أعد الإضافات واحدة تلو الأخرى — وآخر إضافة تفعّلها قبل عودة الخطأ هي التي ينبغي الإبلاغ عنها، مع إرفاق سطر السجل.