حل أخطاء ووردبريس الشائعة: الشاشة البيضاء والخطأ الحرج وغيرهما

يكاد الخطأ الحرج (critical error) أو الشاشة البيضاء (white screen of death) في WordPress (ووردبريس) يأتي دائمًا من قائمة قصيرة من الأسباب: إضافة أو قالب معيب، أو مشكلة في ذاكرة PHP أو في إصداره، أو ملف تالف، أو عطل في قاعدة البيانات أو الخادم. عالج المشكلة بالترتيب: خذ نسخة احتياطية، واقرأ الخطأ والسجلات (logs)، ثم عطّل الأشياء واحدًا بعد الآخر حتى يعود الموقع. والحلول التالية مأخوذة من التوثيق الرسمي لـ WordPress وWooCommerce حتى أكتوبر 2026.

طريقة هادئة لحل أي خطأ في WordPress

التعجل يزيد الانقطاع سوءًا، لذا اتبع الترتيب نفسه في كل مرة.

1. دوّن ما تراه. التقط صورة للشاشة (screenshot) للرسالة، ودوّن الوقت وما تغيّر قبلها مباشرة: تحديث، أو إضافة جديدة، أو تعديل في القالب، أو نقل للموقع.
2. خذ نسخة احتياطية. انسخ الملفات وقاعدة البيانات، حتى لو كان الموقع معطّلًا. فمعظم الحلول أدناه تعيد تسمية ملفات أو تعدّلها، وهذه النسخة هي طريق العودة. راجع كيف تأخذ نسخة احتياطية من WordPress.
3. اقرأ الخطأ والسجلات. استعن بالنص الظاهر على الشاشة، والبريد الذي أرسلته WordPress، وسجل أخطاء استضافتك، وwp-content/debug.log.
4. اكتشف السبب بالاستبعاد. ابدأ بالإضافات، ثم القالب، ثم الذاكرة وإصدار PHP، ثم الملفات، ثم الاستضافة. غيّر شيئًا واحدًا، واختبر، وتراجع عنه إن لم يفد.

رسالة الخطأ الحرج في WordPress ووضع الاسترداد

تقول الرسالة «There has been a critical error on this website». وتذكر صفحة الأخطاء الشائعة في WordPress تعارض الإضافات، ومشكلات توافق القوالب، وإصدار PHP غير المتوافق، وحد الذاكرة، والملفات التالفة بوصفها الأسباب المعتادة.

وضع الاسترداد (Recovery mode) موجود منذ WordPress 5.2. عندما ترصد WordPress خطأ PHP فادحًا أثناء تحميل صفحة عادية (لا في cron أو المهام الخلفية)، يرى الزوار شاشة الخطأ، ويتلقى مدير الموقع بريدًا فيه رابط لتسجيل الدخول. وتُوقَف الإضافة أو القالب المعيب مؤقتًا في جلستك الإدارية وحدها، فتستطيع تعطيله من Plugins أو Appearance > Themes، ثم تختار Exit Recovery Mode.

إن لم يصل البريد، فتأكد أن Administration Email Address (عنوان البريد الإلكتروني للإدارة) في Settings > General يقرؤه شخص ما، وابحث في مجلد الرسائل غير المرغوبة. وتحذّر WordPress من أن الرسالة قد تُصفّى إذا وقع الخطأ قبل أن تُحمَّل إضافة البريد لديك. استخدم طريقة الملفات الموضّحة أدناه.

شاشة WordPress البيضاء (white screen of death)، والإضافات والقوالب

تقول صفحة الأخطاء الشائعة إن أخطاء PHP وأخطاء قاعدة البيانات كليهما قد تظهر شاشةً بيضاء، وإن كانت WordPress تعرض في بعض الحالات رسالة الخطأ الحرج بدلًا منها. والحلول واحدة.

عطّل كل الإضافات أو إضافة واحدة عبر نظام الملفات

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

1. في wp-content، غيّر اسم plugins إلى plugins.hold. فتُبلغ WordPress بأن الإضافات مفقودة، وهذا يعطّلها.
2. افتح ‎/wp-admin/plugins.php وسجّل الدخول، ثم أعد اسم المجلد إلى plugins. وتقول الأسئلة الشائعة لاستكشاف الأخطاء إن هذا يُبقي إعدادات الإضافات لكنه يترك كل إضافة معطّلة.
3. أعد تفعيل الإضافات واحدة في كل مرة، واختبر بعد كل واحدة. والإضافة التي تعيد الخطأ هي السبب.

ولاختبار إضافة واحدة مشتبه بها، غيّر اسم مجلدها فقط، مثل hello-dolly إلى hello-dolly-1، كما تفعل وثائق وضع الاسترداد. وإعادة التسمية لا تحذف شيئًا.

بدّل إلى قالب افتراضي

إن لم تكن الإضافات هي السبب، ففعّل قالبًا افتراضيًا من Appearance > Themes. وإن لم تستطع دخول لوحة الإدارة، فغيّر اسم مجلد القالب النشط في wp-content/themes. فتنتقل WordPress حينئذٍ إلى قالب احتياطي، هو أحدث قالب افتراضي من قوالب النواة (core) الموجودة في الموقع (مرجع)، فتأكد أن أحدها مثبّت. وإن عاد الموقع، فافحص آخر تحديث للقالب وأي شيفرة أضفتها إليه.

اقرأ السجلات: WP_DEBUG وWP_DEBUG_LOG

تعطي وثائق تصحيح الأخطاء في WordPress هذه الإعدادات. انسخ 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_LOG الرسائل في debug.log داخل مجلد المحتوى، وهو عادةً wp-content/debug.log، ولا يعمل إلا ما دام WP_DEBUG مضبوطًا على true. وضبط WP_DEBUG_DISPLAY على false يُبعد الرسائل عن الصفحة. وتقول الوثائق إن WP_DEBUG غير موصى به في المواقع الحية، لذا فضّل النسخة التجريبية. وتنبّه Site Health إلى عرض الأخطاء وإلى احتمال أن يكون ملف السجل عامًا معًا، لأن مخرجات التصحيح قد تحتوي معلومات حساسة.

في السجل، يحمل أحدث سطر «Fatal error» مسارًا تحت wp-content/plugins/‎ أو wp-content/themes/‎ يسمّي المتسبب. ويحتفظ WooCommerce أيضًا بملف أخطاء فادحة تحت WooCommerce > Status > Logs، وهذا الملف لا يتضمن أخطاء خادم الويب مثل انتهاء المهلة (timeouts).

وبعد ذلك استرجع نسختك من wp-config.php، أو اضبط WP_DEBUG على false وأزل الأسطر الأخرى، ثم احذف debug.log.

أخطاء قاعدة البيانات و500 والذاكرة

خطأ إنشاء الاتصال بقاعدة البيانات (Error establishing a database connection)

تقول صفحة الأخطاء الشائعة إن سببه عادةً ملف wp-config.php: تحقق من اسم قاعدة البيانات واسم المستخدم وكلمة المرور والمضيف (host). وإلا فقد يكون السبب استضافتك: قاعدة بيانات تجاوزت حصتها أو خادم متوقف. وإذا أشار سجل إلى جدول تالف، فإن وثائق wp-config تصف إعدادًا للإصلاح التلقائي. خذ نسخة احتياطية من قاعدة البيانات أولًا:

define( 'WP_ALLOW_REPAIR', true );

فعّله عند الحاجة فقط، وأزله بمجرد حل المشكلة: فما دام مفعّلًا لا يحتاج الزائر إلى تسجيل الدخول لاستخدام سكربت الإصلاح في ‎/wp-admin/maint/repair.php.

خطأ الخادم الداخلي 500 وملف ‎.htaccess

تذكر صفحة الأخطاء الشائعة أن ملف ‎.htaccess التالف هو السبب الأرجح. عبر SFTP، غيّر اسم ‎.htaccess إلى ‎.htaccess_old (فهو ملف مخفي، فأظهر الملفات المخفية) وأعد تحميل الصفحة. فإن نجح ذلك، فافتح Settings > Permalinks واحفظ: فتكتب WordPress ملفًا جديدًا، أو تعرض القواعد لتلصقها إن لم تستطع، كما تشرح وثائق الروابط الدائمة. وإن بقي الخطأ، فعطّل الإضافات، وبدّل القالب، وارفع حد الذاكرة، وأخيرًا أعد رفع wp-admin وwp-includes من تنزيل جديد لـ WordPress، وليس wp-content أو wp-config.php أبدًا. وليس في Nginx ملف ‎.htaccess: اطلب من استضافتك سجل الأخطاء.

أخطاء حد ذاكرة PHP

تعني رسالة «Allowed memory size exhausted» أن WordPress لم تجد ذاكرة كافية للمهمة. ويقول دليل حد الذاكرة في WooCommerce أن تضيف هذا السطر إلى wp-config.php (بعد نسخه أولًا) فوق التعليق «That's all, stop editing»، ويوصي بـ 256 MB:

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

إن لم يكن له أثر، فقد تفرض استضافتك حدًا أقصى، فاسألها أو اضبط memory_limit في php.ini. ويعرض WooCommerce > Status حد ذاكرة WP في تقرير حالة النظام. وإذا نفدت الذاكرة مجددًا بعد قليل، فاشتبه في إضافة.

وضع الصيانة وأخطاء 404 وحلقات تسجيل الدخول والمحتوى المختلط

الموقع عالق في وضع الصيانة

أثناء التحديث تضع WordPress ملف ‎.maintenance في المجلد الذي يحتوي wp-admin. وإذا انقطع التحديث، يظل الزوار يرون «Briefly unavailable for scheduled maintenance». انتظر بضع دقائق، ثم احذف ‎.maintenance عبر SFTP وافحص Dashboard > Updates، لأن الأسئلة الشائعة تنص على أن الترقية ينبغي أن تعمل مرة أخرى تحسبًا لفشلها.

أخطاء 404 في المقالات بعد النقل

إذا حُمّلت الصفحة الرئيسية لكن المقالات تعيد خطأ 404، فافتح Settings > Permalinks: فزيارة الشاشة تعيد ضبط (flush) قواعد إعادة الكتابة (rewrite rules)، والحفظ يعرض إما «Permalink structure updated» أو القواعد التي تلصقها في ‎.htaccess. ويقول دليل النقل أن تعيد ضبط الروابط الدائمة عندما يبدأ الموقع المنقول بالعمل فعليًا، وأن تفحص WordPress Address وSite Address. وعلى Apache، اسأل أيضًا هل mod_rewrite مفعّل. راجع نقل موقع WordPress إلى استضافة جديدة.

حلقة إعادة التوجيه عند تسجيل الدخول

إذا أعادت صفحة تسجيل الدخول تحميل نفسها بعد إدخال بيانات صحيحة، فإن دليل تسجيل الدخول يقول بالترتيب: امسح ملفات تعريف الارتباط (cookies) الخاصة بموقعك، وتحقق في wp-config.php من صحة WP_HOME وWP_SITEURL، وتحقق من قيمتي siteurl وhome في جدول الخيارات (options table)، وغيّر اسم مجلد plugins. ولفرض العنوان الصحيح (بعد نسخ wp-config.php أولًا) يعرض الدليل:

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );

استبدل example.com بنطاقك. تتجاوز هذه الأسطر القيم المخزنة في قاعدة البيانات دون أن تغيّرها. وبخصوص رسالة «cookies are blocked»، يقول الدليل أن تستثني wp-login.php من التخزين المؤقت للصفحات (page caching).

المحتوى المختلط ومشكلات HTTPS

المحتوى المختلط (mixed content) هو صفحة HTTPS تحمّل صورًا أو سكربتات أو أوراق أنماط عبر HTTP؛ وتحظر معظم المتصفحات المحتوى النشط مثل السكربتات. اعثر على المتسببين في أدوات المطوّر في متصفحك، وتحقق أن WordPress Address (URL) وSite Address (URL) في Settings > General تبدأ بـ https://‎، واستبدل روابط http://‎ القديمة في قاعدة البيانات. ويحذّر دليل النقل من أن البحث والاستبدال البسيط قد يفسد البيانات المتسلسلة (serialised data) وأن عمود guid يجب ألا يتغير، لذا خذ نسخة احتياطية واستخدم إضافة أو الأمر wp search-replace في WP-CLI مع ‎--dry-run أولًا.

متى تسأل استضافتك

اسأل استضافتك عندما يستمر خطأ قاعدة البيانات بعد أن تأكدت من بيانات wp-config.php، وعندما تستمر أخطاء 500 بعد أن غيّرت اسم ‎.htaccess ومجلد الإضافات، وعندما لا يتغير حد الذاكرة، وعندما لا تستطيع قراءة سجل الأخطاء، أو عندما تشك في وقوع اختراق (راجع قائمة التحقق من أمان WordPress). أرسل نص الخطأ بحروفه، والوقت والمنطقة الزمنية، وما تغيّر وما جرّبته، مع تقرير حالة النظام في WooCommerce (Get system report ثم Copy for support) إن استطعت الوصول إليه. وإذا كانت إضافة أو قالب اشتريته من DevMarket هو السبب، فراجع مدة الدعم في صفحته.

الأسئلة الشائعة

هل الخطأ الحرج هو نفسه الشاشة البيضاء؟

أسبابهما مشتركة. والخطأ الحرج هو الرسالة التي تعرضها WordPress، مع بريد الاسترداد، عندما ترصد الخطأ.

لم يصلني بريد الاسترداد. ماذا أفعل؟

تحقق من Administration Email Address ومن الرسائل غير المرغوبة، ثم غيّر اسم مجلد plugins كما هو موضح أعلاه.

هل تغيير اسم مجلد plugins يحذف إضافاتي أو إعداداتها؟

لا. إنه يعطّل الإضافات ويُبقي إعداداتها؛ وأنت تعيد تفعيلها يدويًا.

هل من الآمن ترك WP_DEBUG مفعّلًا؟

لا. لا توصي WordPress بتفعيل التصحيح في المواقع الحية، وتنبّه إليه Site Health.

الخطوات التالية

بعد أن يعود الموقع، حدّثه باتباع الروتين الموضح في كيف تحدّث WordPress وWooCommerce بأمان، وجدول المهام الواردة في قائمة التحقق من صيانة WordPress. ويمكنك أيضًا تصفح إضافات WordPress المرخّصة، وتعرض كل صفحة منها مدة الدعم وسياسة التحديث.