الشاشة البيضاء في WordPress أوWhite Screen of Death تعني أن تنفيذ PHP أوعملية تحميل WordPress توقفت قبل إخراج الصفحة بصورة طبيعية. في الإصدارات الحديثة قد ترى بدل الصفحة البيضاء رسالة “There has been a critical error on this website” لأن WordPress لديها Fatal Error Handler وRecovery Mode منذ الإصدار 5.2.

الخلاصة: لا تبدأ بحذف ملفات أوتعطيل كل Plugins عشوائيًا. خذ Backup/Snapshot إن أمكن، راجع Admin email وRecovery Mode أولًا، ثم Server/PHP logs. إذا احتجت Logging على موقع عام، أخفِ الأخطاء عن الزوار باستخدام WP_DEBUG_DISPLAY=false. بعد تحديد Plugin/Theme/Custom code المسببة، اعزلها فقط ثم اختبر.

قبل أي خطوة: هل لديك شاشة بيضاء أمCritical Error؟

العرض	المعنى المحتمل
صفحة بيضاء تمامًا	Fatal PHP error، output failure، memory، أوServer/PHP issue
There has been a critical error	WordPress Fatal Error Handler التقطت Fatal error
500 Internal Server Error	قد يكون PHP/Server/.htaccess/permissions وغيرها
Error establishing a database connection	مشكلة Database مختلفة عن WSOD التقليدية
Briefly unavailable for scheduled maintenance	Update/maintenance state وليس بالضرورة Fatal error

الخطوة 1: سجّل آخر تغيير

قبل لمس الموقع، اسأل:

هل حدث Plugin update؟
هل تم تغيير PHP version؟
هل عدلت functions.php أوCode Snippet؟
هل تم تحديث WooCommerce؟
هل تم تغيير Theme؟
هل حدث Deployment أوImport؟

آخر تغيير ليس دليلًا قطعيًا، لكنه يقلل مساحة البحث.

الخطوة 2: خذ Backup أوSnapshot قبل التعديل

إذا الاستضافة توفر Snapshot/File+Database backup، التقط نقطة استعادة قبل إعادة تسمية مجلدات أوتعديل wp-config.php.

لو الموقع متوقف تمامًا ولا يمكن أخذ Backup من WordPress، استخدم أدوات الاستضافة أوانسخ الملفات وDatabase بالطريقة المتاحة لديك.

الخطوة 3: افحص بريد Administrator وRecovery Mode

WordPress Recovery Mode مصممة تحديدًا لحالات Fatal PHP error. عند اكتشاف خطأ مناسب، WordPress قد ترسل رسالة إلى بريد Administrator تحتوي:

معلومات عن الخطأ.
Plugin أوTheme المتسببة عندما يمكن تحديدها.
رابط دخول خاص إلى Recovery Mode.

داخل Recovery Mode، المكون الذي فشل يمكن إيقافه مؤقتًا لجلسة Administrator حتى تتمكن من دخول Dashboard وإصلاح المشكلة.

لو وصلت رسالة Recovery Mode

افتح الرابط من بريد Administrator.
سجّل الدخول.
اقرأ Notice التي تحدد Plugin/Theme.
Deactivate المكون المسبب أوارجع آخر تعديل.
اختبر الموقع.
اخرج من Recovery Mode بعد الإصلاح.

لم تصل رسالة Recovery Mode؟

عدم وصول البريد لا يعني أن Recovery Mode لم تعمل. قد تفشل Email delivery أوتذهب الرسالة إلى Spam. انتقل إلى Logs وتشخيص Server بدل إعادة تثبيت WordPress مباشرة.

الخطوة 4: راجع PHP/Server Error Log

أفضل دليل غالبًا هو Fatal error نفسها. من لوحة الاستضافة ابحث عن:

PHP error log.
Web server error log.
Application logs.
WooCommerce logs إذا الخطأ مرتبط بعملية متجر.

مثال:

PHP Fatal error: Uncaught Error: Call to undefined function ...
in /wp-content/plugins/example-plugin/file.php on line 123

هذا أقوى من تخمين أن “كل الإضافات فيها مشكلة”.

الخطوة 5: Logging داخل WordPress بدون كشف الأخطاء للزوار

إذا تحتاج Debug logging مؤقتة ولا توجد Logs مناسبة، استخدم إعدادًا متحكمًا فيه:

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

لا تستخدم WP_DEBUG_DISPLAY=true على Production لأن رسائل الخطأ قد تكشف Paths أوبيانات تقنية للزوار.

WordPress الرسمية توصي بأدوات Debug أساسًا في Development/Staging. إذا اضطررت لاستخدام Logging مؤقتًا على Production، أبقِ العرض مغلقًا وأوقف Debug بعد انتهاء التشخيص.

تنبيه: debug.log قد تكون داخل Web Root

المكان الافتراضي غالبًا wp-content/debug.log. هذا قد يكون قابلًا للوصول عبر الويب حسب إعداد الخادم. الأفضل توجيه Log إلى مسار محمي خارج Public root عندما تسمح البيئة، أوحمايتها ثم حذف/إيقاف Logging بعد التشخيص.

الخطوة 6: إذا Log تحدد Plugin بعينها

ابدأ بالمكون المحدد فقط.

لو Dashboard تعمل

Plugins → Installed Plugins → Deactivate للمكون المسبب.

لو Dashboard لا تعمل

من SFTP/File Manager غيّر اسم مجلد Plugin المحددة:

/wp-content/plugins/example-plugin/
→
/wp-content/plugins/example-plugin-disabled/

WordPress لن تستطيع تحميل Plugin بهذا المسار، فيتم عزلها بدون حذف ملفاتها.

الخطوة 7: لو لا تعرف أي Plugin تسبب المشكلة

تعطيل كل Plugins يصبح Fallback وليس أول خطوة.

إذا لديك WP-CLI:

wp plugin deactivate --all

أويمكن مؤقتًا إعادة تسمية مجلد:

/wp-content/plugins/
→
/wp-content/plugins-disabled/

إذا عاد الموقع:

أعد اسم المجلد إلى plugins.
ستبقى Plugins معطلة في كثير من السيناريوهات.
فعّلها تدريجيًا.
اختبر بعد كل تفعيل.

متجر WooCommerce: لا تعطل كل Plugins بلا حساب

في Production store، تعطيل WooCommerce أوPayment/Shipping plugins قد يؤثر على:

Checkout.
Background jobs.
Webhooks.
Emails.
Subscriptions.

استخدم Maintenance window أوStaging إن أمكن، وابدأ بالمكون الذي تحدده Logs.

الخطوة 8: Theme error

إذا Stack trace تشير إلى Theme:

ارجع آخر تعديل في Child Theme.
أوغيّر Theme مؤقتًا من Dashboard.
أوغيّر اسم مجلد Active Theme عبر File Manager إذا Dashboard غير متاحة.

يجب أن يكون هناك Default theme مثبتة حتى يستطيع WordPress التحول إليها تلقائيًا في بعض الحالات.

لا تعدل Parent Theme مباشرة

إذا الخطأ جاء من تعديل يدوي في Parent Theme، أصلح/استرجع الملف ثم انقل التخصيص لاحقًا إلى Child Theme أوPlugin مناسبة. تعديل Parent يجعل Updates تمسح التغيير ويصعّب Rollback.

الخطوة 9: Custom code / Code Snippets

إذا بدأت المشكلة بعد إضافة PHP snippet:

أوقف Snippet من Recovery Mode إن أمكن.
أوDeactivate Plugin التي تدير Snippets.
إذا الكود داخل functions.php ارجع Commit/Backup السابقة.

Syntax error واحدة مثل قوس مفقود قد توقف تحميل PHP بالكامل.

الخطوة 10: Memory exhaustion

إذا Log تحتوي مثلًا:

Allowed memory size of ... bytes exhausted

فهنا لديك دليل Memory. لا ترفع الحد عشوائيًا قبل فهم سبب الاستهلاك.

راجع:

Plugin/عملية تستهلك Memory بصورة غير طبيعية.
PHP memory_limit على Server.
WordPress memory constants.
Import أوImage processing أوQuery ضخمة.

رفع Memory قد يخفي Leak أوQuery سيئة بدل إصلاحها.

WP_MEMORY_LIMIT ليست أقوى من Server دائمًا

حتى لو رفعت WordPress limit، Hosting/PHP configuration قد تفرض سقفًا أقل أوأعلى حسب البيئة. تحقق من Site Health أوPHP info أوSupport.

الخطوة 11: PHP version incompatibility

بعد تغيير PHP قد تظهر:

Undefined functions.
Deprecated/removed features.
Type errors.
Plugin قديمة غير متوافقة.

إذا المشكلة بدأت بعد Upgrade PHP:

راجع Error log.
راجع Compatibility للمكون المسبب.
حدّثه إن كانت نسخة متوافقة موجودة.
يمكن الرجوع مؤقتًا إلى PHP مدعومة سابقة كإجراء Recovery فقط، ثم تحديث Stack.

لا تبقَ على PHP قديمة كحل دائم

Downgrade قد يعيد الموقع مؤقتًا لكنه لا يحل Dependency قديمة. الهدف النهائي استخدام إصدار PHP مدعوم من الاستضافة ومكونات الموقع.

الخطوة 12: Failed update وMaintenance mode

إذا الموقع يعرض:

Briefly unavailable for scheduled maintenance. Check back in a minute.

فهذه ليست WSOD كلاسيكية. قد تكون عملية Update تركت ملف .maintenance بعد انقطاع.

تحقق أولًا أن Update ليست ما زالت تعمل، ثم عالج Maintenance state وأعد اختبار الملفات/التحديث.

الخطوة 13: Core files تالفة

إذا Logs وChecks تشير إلى Core file مفقودة/معدلة، يمكن إعادة تثبيت WordPress Core من مصدر رسمي.

لكن قبلها:

Backup.
لا تستبدل wp-content.
لا تمسح wp-config.php.
استخدم WP-CLI checksum إن توفر لتحديد الملفات المعدلة.

لا تبدأ بإعادة تثبيت Core لمجرد أن الصفحة بيضاء.

الخطوة 14: Database error ليست WSOD عادية

إذا ترى Error establishing a database connection، انتقل لتشخيص:

DB server.
Credentials.
Host.
Database service.
Connection limits.

تعطيل Plugins قد لا يكون الحل المناسب هنا.

الخطوة 15: .htaccess / Rewrite

خطأ Syntax في Apache configuration قد ينتج 500 وليس White Screen خالصة. إذا المشكلة بدأت بعد تعديل .htaccess، استرجع آخر نسخة سليمة واختبر Server error log.

الخطوة 16: Permissions

Permissions خاطئة قد تمنع PHP/Web server من قراءة ملفات. لا تستخدم 777 كحل عام.

استعن بإعدادات الاستضافة/المالك الصحيحة بدل فتح الصلاحيات للجميع.

الخطوة 17: راقب URL واحدة أمكل الموقع

لو الشاشة البيضاء في صفحة بعينها فقط، قد يكون السبب:

Template محددة.
Shortcode.
Block.
Query.
Plugin تعمل على هذا Route فقط.

لا تعطل الموقع كاملًا إذا المشكلة محصورة في Template واحدة.

الخطوة 18: Admin فقط أمFrontend فقط؟

النطاق	ما يرجح فحصه
Frontend فقط	Theme/templates/frontend plugins
Admin فقط	Admin hooks/plugins/memory
صفحة واحدة	Template/query/content-specific code
الموقع كله	Bootstrap/plugin/theme/PHP/server

الخطوة 19: بعد عودة الموقع لا تنتهِ المهمة

إذا عطلت Plugin وعاد الموقع، نفّذ Root Cause cleanup:

حدد الإصدار الذي كسر الموقع.
راجع Changelog/Support.
حدّث أواستبدل المكون.
امسح Cache.
اختبر Logs.
أعد اختبار Critical flows.
أوقف Debug المؤقت.

الخطوة 20: أوقف Debug بعد التشخيص

أعد Production إلى إعداد آمن، مثل:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

ثم تعامل مع أي Debug log تم إنشاؤها وفق سياسة الأمان لديك.

ما الذي لا أفعله؟

لا أحذف wp-content.
لا أحذف Database.
لا أضع Permissions 777.
لا أعرض PHP errors للعامة.
لا أرفع Memory بلا دليل.
لا أغير PHP عدة مرات بلا Logging.
لا أعيد تثبيت WordPress قبل التشخيص.
لا أعدل Core.

Workflow مختصر للتشخيص

Backup/Snapshot.
Last change.
Recovery Mode email.
PHP/Server logs.
Controlled WordPress logging.
عزل Plugin/Theme المحددة.
Fallback: disable all plugins فقط إذا السبب غير معروف.
PHP/Memory/Core checks حسب الخطأ.
Fix root cause.
QA + disable debug.

كيف تمنع تكرار White Screen؟

Staging للتحديثات الحساسة.
Backups قابلة للاستعادة.
Update policy منتظمة.
عدم تعديل Core/Parent theme.
Git للكود المخصص.
PHP compatibility checks.
Monitoring وLogs.
عدم تثبيت Plugins غير موثوقة.

راجع أيضًا تجهيز WordPress للإنتاج لبناء Backup/Update/Rollback workflow.

أسئلة شائعة

هل الشاشة البيضاء تعني أن البيانات ضاعت؟

لا. غالبًا هي Runtime/Fatal error تمنع عرض الصفحة، بينما Database والملفات ما زالت موجودة. لا تحذف شيئًا قبل التشخيص.

ما أول شيء أفعله؟

احفظ نقطة استعادة إن أمكن، ثم راجع Admin email لرسالة Recovery Mode وError logs.

هل أفعّل WP_DEBUG_DISPLAY؟

ليس على Production. إذا تحتاج Logging مؤقتة استخدم WP_DEBUG_LOG=true مع WP_DEBUG_DISPLAY=false وتأكد أن PHP نفسها لا تعرض Errors.

هل أعيد تسمية مجلد plugins كله؟

فقط كFallback إذا لا تعرف المكون المسبب ولا تستطيع دخول Dashboard/Recovery Mode. إذا Log تحدد Plugin بعينها، اعزلها وحدها.

هل Recovery Mode تعمل مع كل الأخطاء؟

لا. هي مصممة لحالات Fatal PHP معينة أثناء Page load، ولا تعني أن كل Server/Database/background error ستدخل Recovery Mode.

الخلاصة

حل White Screen في WordPress هو عملية تشخيص لا لعبة تجربة وخطأ. ابدأ Recovery Mode وLogs، أخفِ الأخطاء عن الزوار، اعزل المكون الذي تشير إليه Stack trace، ثم أصلح Root Cause واختبر. كلما قلّت التغييرات العشوائية، قل خطر تحويل عطل واحد إلى عدة أعطال جديدة.