إذا ظهرت لك رسالة There has been a critical error on this website أو “حدث خطأ حرج في هذا الموقع”، فهذا يعني أن هناك مشكلة منعت ووردبريس من تنفيذ جزء من الموقع بشكل طبيعي.
قد يكون السبب إضافة (Plugin)، أو قالب (Theme)، أو إصدار PHP غير متوافق، أو مشكلة في الذاكرة، أو كود مخصص تسبب في خطأ PHP.
في هذا الدليل سنشرح كيفية حل الخطأ الحرج في ووردبريس خطوة بخطوة، بداية من أسهل الحلول، وصولًا إلى استخدام Recovery Mode وdebug.log لتحديد سبب المشكلة.
وإذا كنت تواجه أكثر من مشكلة في موقعك، يمكنك أيضًا الرجوع إلى دليلنا الشامل حول مشاكل ووردبريس: 15 مشكلة شائعة وحلولها وكيفية إصلاحها.
ما هو الخطأ الحرج في ووردبريس؟
الخطأ الحرج (Critical Error) هو خطأ يمنع ووردبريس من تشغيل جزء من الموقع كما ينبغي.
عندما تظهر رسالة There has been a critical error on this website فهذا يعني أن شيئًا ما تسبب في خطأ يمنع ووردبريس من العمل بالشكل المتوقع.
وفقًا لوثائق WordPress الرسمية، يمكن أن يرتبط الخطأ الحرج بمشاكل في الإضافات أو القوالب أو إصدار PHP أو حدود الذاكرة أو ملفات ووردبريس.
يمكنك الاطلاع على دليل الأخطاء الشائعة في WordPress لمعرفة المزيد عن طرق تشخيص هذه المشاكل.
لماذا يظهر الخطأ الحرج في ووردبريس؟
هناك عدة أسباب محتملة لظهور الخطأ الحرج، وأهمها:
- إضافة ووردبريس بها مشكلة.
- تعارض بين إضافتين.
- تعارض بين إضافة والقالب.
- قالب يحتوي على خطأ PHP.
- إصدار PHP غير متوافق مع إحدى الإضافات أو القوالب.
- الوصول إلى حد الذاكرة المتاح.
- كود مخصص يحتوي على خطأ.
- تحديث فاشل أو غير مكتمل.
- ملفات ووردبريس تالفة أو ناقصة.
- مشكلة في إعدادات الخادم أو الاستضافة.
لهذا السبب لا يوجد حل واحد يناسب جميع الحالات. الطريقة الصحيحة هي تحديد المكون الذي تسبب في الخطأ أولًا، ثم إصلاحه أو تعطيله.
الحل الأول: افحص البريد الإلكتروني الخاص بمدير الموقع
إذا اكتشف ووردبريس خطأً حرجًا مناسبًا لـ Recovery Mode، فقد يرسل رسالة إلى البريد الإلكتروني الخاص بمدير الموقع تحتوي على معلومات تساعدك في تشخيص المشكلة.
قد تحتوي الرسالة على تفاصيل مرتبطة بالمشكلة، بالإضافة إلى رابط يسمح لك بالدخول إلى الموقع في وضع الاسترداد.
لذلك إذا ظهرت لك رسالة الخطأ الحرج، افحص بريد مدير الموقع قبل البدء في تعديل ملفات الموقع.
إذا وجدت رسالة من WordPress، لا تحذفها قبل قراءة التفاصيل الموجودة فيها.
يمكنك مراجعة شرح Recovery Mode الرسمي من WordPress.
الحل الثاني: استخدم Recovery Mode
يحتوي ووردبريس على ميزة مدمجة تسمى Recovery Mode، وهي مصممة لمساعدتك على استعادة الوصول إلى الموقع عندما يتسبب خطأ PHP خطير في تعطيل الموقع.
عندما يكتشف ووردبريس خطأً مناسبًا لـ Recovery Mode، يمكن أن يرسل رابطًا إلى بريد مدير الموقع للدخول إلى وضع الاسترداد.
داخل Recovery Mode يمكن تعطيل الإضافة أو القالب الذي تسبب في المشكلة مؤقتًا لجلسة الإدارة، مما يسمح لك بالدخول إلى لوحة التحكم وتشخيص الخطأ.
بعد تحديد السبب وإصلاح المشكلة، يمكنك الخروج من Recovery Mode والتأكد من أن الموقع يعمل بشكل طبيعي.
راجع شرح Recovery Mode الرسمي من WordPress لمعرفة طريقة عمل هذه الميزة.
الحل الثالث: عطّل الإضافة التي سببت المشكلة
إذا بدأت المشكلة مباشرة بعد تثبيت إضافة جديدة أو تحديث إضافة موجودة، فهناك احتمال أن تكون الإضافة مرتبطة بالخطأ.
إذا كان بإمكانك الدخول إلى لوحة التحكم:
- اذهب إلى الإضافات.
- افتح قائمة الإضافات المثبتة.
- عطّل الإضافة التي بدأت المشكلة بعدها.
- افحص الموقع مرة أخرى.
إذا عاد الموقع للعمل بعد تعطيل الإضافة، فهذا يعطيك مؤشرًا قويًا على أن الإضافة كانت سبب المشكلة أو جزءًا من التعارض.
إذا لم تكن متأكدًا من الإضافة المسؤولة، يمكنك تعطيل الإضافات بشكل مؤقت واختبار الموقع، ثم إعادة تفعيلها واحدة تلو الأخرى لتحديد الإضافة المسببة للمشكلة.
راجع أيضًا دليل WordPress الرسمي للأخطاء الشائعة لمعرفة طرق التعامل مع مشاكل الإضافات.
ماذا تفعل إذا لم تستطع الدخول إلى لوحة التحكم؟
إذا كان الخطأ يمنعك من الوصول إلى لوحة التحكم، يمكنك التعامل مع الإضافات من خلال ملفات الموقع باستخدام مدير الملفات في الاستضافة أو FTP.
في هذه الحالة يمكنك الوصول إلى مجلد:
wp-content/pluginsثم تعطيل الإضافات مؤقتًا بالطريقة المناسبة لبيئتك.
لكن قبل تعديل الملفات، من الأفضل أخذ نسخة احتياطية مناسبة من الموقع، خصوصًا إذا لم تكن معتادًا على التعامل مع ملفات WordPress.
توصي وثائق WordPress أيضًا بأخذ نسخة احتياطية قبل إجراء تغييرات مهمة على الموقع.
يمكنك مراجعة دليل تصحيح أخطاء WordPress الرسمي.
الحل الرابع: افحص القالب
إذا عطّلت الإضافات ولم تختفِ المشكلة، فقد يكون القالب هو السبب.
يمكن أن يحدث ذلك بعد:
- تحديث القالب.
- تعديل ملفات القالب.
- إضافة كود مخصص.
- استخدام قالب غير متوافق مع إصدار WordPress أو PHP.
إذا كان بإمكانك الوصول إلى لوحة التحكم، يمكنك تجربة قالب افتراضي من قوالب WordPress لمعرفة ما إذا كانت المشكلة مرتبطة بالقالب الحالي.
إذا اختفى الخطأ بعد تغيير القالب، فهذا يعطيك مؤشرًا قويًا على أن المشكلة مرتبطة بالقالب أو أحد تعديلاته.
إذا لم تستطع الوصول إلى لوحة التحكم، يمكن أن يكون التعامل مع ملفات القالب من خلال مدير الملفات أو FTP جزءًا من عملية التشخيص.
الحل الخامس: تحقق من إصدار PHP
PHP جزء أساسي من البيئة التي يعمل فيها ووردبريس، ولذلك فإن عدم توافق إصدار PHP مع إحدى الإضافات أو القوالب قد يؤدي إلى أخطاء.
توصي WordPress حاليًا بأن تدعم الاستضافة PHP 8.3 أو أحدث، بينما تختلف توافقية إصدارات PHP حسب إصدار WordPress والقالب والإضافات المستخدمة.
لذلك لا تغيّر إصدار PHP بشكل عشوائي. تحقق أولًا من توافق مكونات موقعك، وخذ نسخة احتياطية قبل إجراء تغيير مهم على بيئة الإنتاج.
يمكنك مراجعة متطلبات WordPress الرسمية لمعرفة المتطلبات الحالية.
هل تحديث PHP يحل الخطأ الحرج دائمًا؟
لا.
تحديث PHP قد يحل المشكلة إذا كان سببها عدم توافق أو إصدار قديم، لكنه قد يؤدي أيضًا إلى ظهور مشاكل جديدة إذا كانت إحدى الإضافات أو القوالب غير متوافقة مع الإصدار الجديد.
لهذا السبب يجب التعامل مع تغيير إصدار PHP كجزء من عملية التشخيص، وليس كحل عشوائي لكل خطأ حرج.
إذا كان موقعك يستخدم إصدار PHP قديمًا، فمن الأفضل التخطيط للترقية بعد التحقق من توافق الإضافات والقالب.
الحل السادس: افحص صحة الموقع من Site Health
يوفر ووردبريس أداة Site Health التي تساعدك على اكتشاف بعض المشاكل المتعلقة بإعدادات الموقع والخادم والإضافات والقوالب وPHP.
يمكنك الوصول إليها من:
أدوات ← صحة الموقع
ثم راجع قسم الحالة لمعرفة المشاكل الحرجة والتحسينات المقترحة.
ومن خلال تبويب المعلومات يمكنك أيضًا رؤية تفاصيل تقنية عن الخادم، وPHP، والقالب، والإضافات وقاعدة البيانات.
راجع شرح Site Health الرسمي من WordPress.
الحل السابع: فعّل WP_DEBUG لمعرفة سبب الخطأ
إذا لم تتمكن من تحديد سبب المشكلة من خلال Recovery Mode، يمكنك استخدام أدوات التصحيح الموجودة في ووردبريس للحصول على معلومات أكثر تفصيلًا عن الخطأ.
من أشهر خيارات التصحيح:
WP_DEBUGWP_DEBUG_LOGWP_DEBUG_DISPLAY
يمكن استخدام WP_DEBUG لتفعيل وضع التصحيح، بينما يسمح WP_DEBUG_LOG بتسجيل الأخطاء في ملف سجل، ويمكن استخدام WP_DEBUG_DISPLAY للتحكم في عرض الأخطاء داخل صفحات الموقع.
توضح وثائق WordPress الرسمية أن إعداد تسجيل الأخطاء يمكن أن يحفظ الأخطاء في ملف:
wp-content/debug.logلكن لا يُنصح بإظهار أخطاء PHP للزوار على الموقع الحي، لأن رسائل الخطأ قد تكشف معلومات تقنية عن الموقع.
لمزيد من التفاصيل، راجع دليل Debugging WordPress الرسمي.
إعداد WP_DEBUG بطريقة أكثر أمانًا
إذا كنت تحتاج إلى تسجيل الأخطاء على موقع حي لأغراض التشخيص، يمكن استخدام إعداد مشابه لما توضحه وثائق WordPress الرسمية:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );يجب وضع هذه الإعدادات في ملف wp-config.php قبل السطر:
/* That's all, stop editing! Happy blogging. */بعد الانتهاء من التشخيص، من الأفضل تعطيل وضع التصحيح على الموقع الحي إذا لم تعد بحاجة إليه.
وتنبه وثائق WordPress إلى أن أدوات التصحيح موجهة أساسًا لبيئات التطوير والاختبار، لذلك يجب استخدامها بحذر على المواقع الحية.
كيف تقرأ ملف debug.log؟
بعد تفعيل تسجيل الأخطاء، قد تجد ملف:
wp-content/debug.logقد يحتوي الملف على عدد كبير من الرسائل، لذلك ركز على الأخطاء التي ظهرت في نفس الوقت الذي بدأت فيه المشكلة.
ابحث خصوصًا عن عبارات مثل:
Fatal errorUncaught ErrorUncaught TypeErrorAllowed memory size- اسم إضافة معينة.
- اسم القالب.
إذا ظهر مسار ملف يحتوي على اسم إضافة أو قالب، فقد يساعدك ذلك في تحديد المكون المرتبط بالمشكلة.
مثال على تحديد الإضافة المسببة للمشكلة
لنفترض أن سجل الأخطاء يحتوي على مسار مشابه لـ:
wp-content/plugins/example-plugin/...هذا لا يعني تلقائيًا أن الإضافة هي السبب الوحيد، لكنه يعطيك نقطة مهمة لبدء التشخيص.
يمكنك تعطيل الإضافة مؤقتًا ثم اختبار الموقع.
إذا اختفى الخطأ، فهذا مؤشر قوي على أن الإضافة مرتبطة بالمشكلة.
ماذا لو كان الخطأ بسبب Memory Limit؟
في بعض الحالات قد يفشل تنفيذ PHP لأن الموقع وصل إلى حد الذاكرة المتاح له.
يمكن أن يحدث ذلك في مواقع تحتوي على إضافات كثيرة أو عمليات ثقيلة، أو عند تنفيذ بعض المهام التي تحتاج إلى موارد أكبر.
لكن رفع Memory Limit بشكل عشوائي ليس دائمًا الحل الأفضل.
قبل زيادة الذاكرة، حاول معرفة العملية التي تستهلك الموارد، لأن زيادة الحد قد تخفي المشكلة بدل معالجة سببها الحقيقي.
يمكن استخدام Site Health ومعلومات الخادم للمساعدة في فهم إعدادات البيئة الحالية.
ماذا لو بدأ الخطأ بعد تحديث إضافة؟
إذا ظهر الخطأ مباشرة بعد تحديث إضافة، فابدأ بتعطيلها واختبار الموقع.
بعد ذلك يمكنك:
- التأكد من وجود إصدار أحدث من الإضافة.
- قراءة سجل التغييرات (Changelog).
- مراجعة صفحة الدعم الخاصة بالإضافة.
- التأكد من توافقها مع إصدار WordPress وPHP المستخدم.
- الرجوع إلى إصدار سابق فقط إذا كان ذلك ضروريًا وكان لديك طريقة آمنة للرجوع.
لا تجعل الرجوع إلى إصدار قديم هو الحل الأول. الأفضل معرفة سبب المشكلة والتأكد من وجود توافق أو تحديث مناسب.
ماذا لو لم تكن الإضافات هي السبب؟
إذا عطلت الإضافات ولم تختفِ المشكلة، انتقل إلى الاحتمالات الأخرى:
- القالب.
- إصدار PHP.
- Memory Limit.
- ملفات WordPress.
- كود مخصص.
- إعدادات الخادم.
- مشكلة في قاعدة البيانات.
وهنا يصبح استخدام سجل الأخطاء وSite Health أكثر أهمية، لأن الهدف هو تحديد السبب بدل تجربة حلول عشوائية.
هل يجب إعادة تثبيت ووردبريس؟
ليس بالضرورة.
إعادة تثبيت WordPress ليست أول خطوة يجب القيام بها عند ظهور Critical Error، خصوصًا إذا كان الخطأ ناتجًا عن إضافة أو قالب أو إصدار PHP.
ابدأ دائمًا بتحديد السبب، ثم تعامل معه مباشرة.
إذا كانت ملفات WordPress نفسها تالفة أو ناقصة، فقد تصبح إعادة تثبيت الملفات النظيفة أحد الحلول المناسبة، لكن يفضل أخذ نسخة احتياطية والتأكد من المشكلة أولًا.
ماذا تفعل إذا كان الخطأ بسبب كود مخصص؟
إذا كنت قد أضفت كود PHP مخصصًا إلى الموقع قبل ظهور الخطأ مباشرة، فضع هذا التغيير ضمن أول الأشياء التي يجب فحصها.
قد يكون الكود موجودًا في:
- ملف
functions.php. - إضافة مخصصة.
- إضافة snippets.
- ملفات القالب.
- ملفات أخرى مرتبطة بوظائف الموقع.
إذا لم تكن متأكدًا من الكود الذي يجب تعديله، لا تحذف أجزاء عشوائية من الموقع. من الأفضل الرجوع إلى النسخة الاحتياطية أو طلب مساعدة من مطور.
الفرق بين الخطأ الحرج والشاشة البيضاء
قد يكون Critical Error وWhite Screen of Death نتيجتين لمشكلة PHP أو تعارض داخل الموقع، لكن طريقة ظهور المشكلة للمستخدم قد تختلف.
في الخطأ الحرج قد يعرض ووردبريس رسالة واضحة تفيد بوجود مشكلة تقنية، بينما قد تظهر الشاشة البيضاء بدون محتوى واضح في بعض الحالات.
توضح وثائق WordPress أن أخطاء PHP وقاعدة البيانات يمكن أن تؤدي إلى الشاشة البيضاء، وأن تعطيل الإضافات والقالب وفحص WP_DEBUG يمكن أن يساعد في التشخيص.
يمكنك مراجعة دليل WordPress للأخطاء الشائعة.
متى تحتاج إلى مساعدة شركة الاستضافة؟
إذا كان الخطأ مرتبطًا بإعدادات الخادم أو PHP أو صلاحيات الملفات أو موارد الاستضافة أو سجلات الخادم، فقد تحتاج إلى التواصل مع شركة الاستضافة.
ويصبح ذلك أكثر أهمية إذا لم يكن لديك وصول إلى الملفات أو إعدادات PHP أو سجلات الخادم.
يمكنك أيضًا استخدام معلومات Site Health → معلومات عند التواصل مع الدعم، لأنها توفر تفاصيل تقنية يمكن أن تساعدهم في تشخيص المشكلة.
أفضل ترتيب لتشخيص الخطأ الحرج
بدل تجربة عشرات الحلول بشكل عشوائي، اتبع هذا الترتيب:
- اقرأ رسالة الخطأ.
- افحص البريد الإلكتروني الخاص بمدير الموقع.
- جرّب Recovery Mode إذا كان متاحًا.
- حدد آخر إضافة أو قالب تم تحديثه أو تثبيته.
- عطّل الإضافة المشتبه بها.
- اختبر القالب.
- راجع إصدار PHP.
- افحص Site Health.
- فعّل تسجيل الأخطاء عند الحاجة.
- راجع
debug.log. - إذا بقي السبب غير واضح، تواصل مع شركة الاستضافة أو مطور WordPress.
كيف تمنع تكرار الخطأ الحرج؟
لا توجد طريقة تضمن عدم ظهور الأخطاء مستقبلًا، لكن يمكنك تقليل احتمالية حدوثها من خلال إدارة الموقع بطريقة منظمة.
- حدّث WordPress والإضافات والقالب باستمرار.
- استخدم إضافات موثوقة ومحدثة.
- تجنب تثبيت إضافات كثيرة بدون حاجة.
- خذ نسخًا احتياطية منتظمة.
- اختبر التحديثات المهمة قبل تطبيقها على الموقع الأساسي عندما يكون ذلك ممكنًا.
- راقب Site Health.
- استخدم إصدار PHP حديثًا ومدعومًا.
- تجنب إضافة أكواد غير موثوقة إلى ملفات القالب.
ملاحظة مهمة قبل تعديل ملفات WordPress
إذا لم تكن معتادًا على تعديل wp-config.php أو ملفات القالب أو ملفات الإضافات، لا تقم بتغيير عدة أشياء في الوقت نفسه.
الأفضل أخذ نسخة احتياطية، ثم إجراء تغيير واحد واختبار الموقع، حتى تعرف بالضبط ما الذي أدى إلى حل المشكلة أو تغييرها.
وتوصي وثائق WordPress بالعمل على بيئة اختبار أو أخذ نسخة احتياطية مناسبة قبل إجراء تعديلات مهمة أثناء عملية التصحيح.
الأسئلة الشائعة
ما سبب ظهور الخطأ الحرج في ووردبريس؟
قد ينتج الخطأ الحرج عن إضافة أو قالب أو كود مخصص أو إصدار PHP غير متوافق أو مشكلة في الذاكرة أو ملفات WordPress.
كيف أصلح Critical Error في WordPress؟
ابدأ بفحص البريد الإلكتروني وRecovery Mode، ثم عطّل الإضافة أو القالب المشتبه به، وافحص PHP وSite Health وسجل الأخطاء إذا لزم الأمر.
هل يمكن أن تكون إضافة واحدة سبب الخطأ؟
نعم. قد تكون الإضافة نفسها بها مشكلة أو قد يحدث تعارض بينها وبين إضافة أخرى أو القالب.
هل تحديث PHP يمكن أن يحل الخطأ الحرج؟
في بعض الحالات نعم، خصوصًا إذا كان هناك عدم توافق بين إصدار PHP والمكونات المستخدمة في الموقع. لكن يجب التحقق من التوافق قبل تغيير الإصدار.
أين يوجد debug.log في ووردبريس؟
عند إعداد تسجيل الأخطاء بالطريقة المناسبة، يكون الملف عادةً داخل:
wp-content/debug.logهل يجب حذف الإضافة التي سببت المشكلة؟
ليس دائمًا. يمكنك أولًا تعطيلها ومعرفة ما إذا كانت المشكلة تختفي. بعد تحديد السبب يمكنك البحث عن تحديث أو حل أو بديل مناسب.
هل يمكن إصلاح الخطأ الحرج بدون حذف الموقع؟
نعم، في كثير من الحالات يمكن إصلاح المشكلة دون حذف الموقع. الهدف أولًا هو تحديد المكون الذي تسبب في الخطأ، مثل إضافة أو قالب أو إعداد PHP أو كود مخصص، ثم التعامل معه مباشرة.
إذا كانت المشكلة التي تواجهها هي 500 Internal Server Error بدل رسالة الخطأ الحرج، راجع أيضًا دليلنا حول حل مشكلة خطأ 500 في ووردبريس: الأسباب والحلول خطوة بخطوة.
الخلاصة
الخطأ الحرج في ووردبريس لا يعني بالضرورة أن موقعك أصبح تالفًا بالكامل. في كثير من الحالات يمكن تحديد السبب من خلال رسالة Recovery Mode أو سجل الأخطاء أو تعطيل الإضافة أو القالب المسبب للمشكلة.
ابدأ دائمًا بالتشخيص بدل تغيير عدة إعدادات في الوقت نفسه. بهذه الطريقة ستتمكن من معرفة السبب الحقيقي وحل المشكلة بأقل مخاطرة ممكنة.
وإذا كنت تريد التعرف على بقية المشاكل الشائعة في ووردبريس وحلولها، راجع أيضًا مشاكل ووردبريس: 15 مشكلة شائعة وحلولها وكيفية إصلاحها.
وإذا لم يكن الخطأ مرتبطًا بـ Critical Error وإنما بمشكلة في سرعة الموقع وأدائه، يمكنك الاطلاع على كيفية تسريع موقع ووردبريس وتحسين Core Web Vitals.
المصادر الرسمية
