حل مشكلة الشاشة البيضاء في ووردبريس بخمس خطوات بسيطة

إذا كان موقعك WordPress إذا ظهرت فجأة صفحة فارغة (أو خطأ 500 بدون رسالة)، فأنت لست "ملعونًا": أنت تواجه خطأ في PHP، أو تعارضًا، أو حدًا للخادم... ويمكن دائمًا تقريبًا تحديد ذلك في أقل من 15 دقيقة.

المشكلة

يشير مصطلح "شاشة الموت البيضاء" (WSOD) إلى ظهور شاشة (أو صفحة) فارغة على واجهة الموقع الإلكتروني العامة أو الإدارية. أحيانًا يُعيد الخادم رمز الخطأ 500، وأحيانًا لا يُعيد أي شيء على الإطلاق.

بحسب مزود خدمة الاستضافة، سترى إحدى هذه الرسائل (أو لن ترى أي رسالة):

HTTP ERROR 500
Internal Server Error

There has been a critical error on this website.

Fatal error: Uncaught Error: Call to undefined function ...
Parse error: syntax error, unexpected '}' ...
Allowed memory size of X bytes exhausted ...

أين ومتى يظهر؟

الواجهة الأمامية : صفحة فارغة على الصفحة الرئيسية، أو مقال، أو صفحات معينة فقط.
المسؤول (/wp-admin) : صفحة فارغة بعد تسجيل الدخول، أو في صفحة معينة (الإضافات، المظهر، Elementor، Divi، إلخ).
AJAX/REST : لم يعد محرر الكتل يعمل، ويبقى Elementor عالقًا على "جارٍ التحميل..."، ويدور Divi Builder بلا نهاية، وتظهر أخطاء في وحدة التحكم.
CRON : المهام المجدولة التي تتعطل (النسخ الاحتياطي، إرسال رسائل البريد الإلكتروني) دون ظهور أعراض واضحة باستثناء السجلات.

الظروف النموذجية التي أواجهها في أغلب الأحيان:

مباشرة بعد تحديث (WordPress 6.9.4 ، أ المساعد(قالب، PHP).
بعد تفعيل إضافة "بسيطة" (ذاكرة التخزين المؤقت، والأمان، والمقتطفات، وعمليات إعادة التوجيه).
بعد لصق رمز تم العثور عليه في منتدى في functions.php.
بعد عملية الترحيل (مضيف جديد، إصدار PHP جديد، أذونات ملفات جديدة).

لمن هذا الدليل؟ إذا كنت مبتدئًا، فسوف تتعلم كيف اجعل ووردبريس يتحدث (تفعيل التسجيل)، تحديد السبب (المكوّن الإضافي/القالب)، إصلاح المشاكل الأكثر شيوعًا (مشاكل الذاكرة، أجزاء التعليمات البرمجية المعطوبة)، واستعادة صلاحيات المدير دون تفاقم الوضع. كل ذلك في وورد 6.9.4 et PHP 8.1 +.

ملخص سريع

يُعدّ WSOD دائمًا تقريبًا خطأ فادح في PHP مُقنّع (أو 500 الخادم). أولاً، أنت بحاجة إلى انظر إلى الخطأ.
مكن WP_DEBUG + WP_DEBUG_LOG و استشارة wp-content/debug.log أو سجلات مزود خدمة الاستضافة.
التشخيص الأكثر فعالية من حيث التكلفة: تعطيل جميع الإضافات ثم أعد تنشيطها واحدة تلو الأخرى، ثم اختبر واحدة منها السمة الافتراضية.
تنشأ العديد من حالات WSOD من حد الذاكرة أو مقتطف مكسور في functions.php.
لاستعادة صلاحيات المسؤول: استخدم وضع الاستردادل إضافة MU خدمات الطوارئ، أو WP-CLI.

الأعراض

شاشة الموت البيضاء ليست مجرد خطأ برمجي واحد. إنها... عرض وهذا قد يخفي عدة أسباب. إليك العلامات التي يمكنك البحث عنها.

شاشة بيضاء كاملة (لا يوجد HTML، وأحيانًا يكون عنوان علامة التبويب فارغًا).
خطأ 500 من جانب المتصفح، وأحيانًا فقط على عناوين URL معينة.
رسالة: "حدث خطأ جسيم..." (يكتشف ووردبريس خطأً فادحاً ويحاول إنقاذك عبر البريد الإلكتروني).
لا يمكن الوصول إلى لوحة التحكم لكن الواجهة الأمامية تعمل، أو العكس صحيح.
محرر كتل مع تحميل لا نهائي (غالباً ما تكون حالة وفاة على طريق REST).
Elementor : شاشة بيضاء في المحرر، أو "تعذر تحميل المعاينة".
ديفي 5 : لا يتم تشغيل أداة الإنشاء، أو تظهر صفحة فارغة بعد الحفظ.
فتح : لا يعرض برنامج Fusion Builder العناصر، أو تظهر صفحة فارغة في وضع التحرير.
وحدة تحكم المتصفح (F12): أخطاء من النوع 500 (Internal Server Error) في /wp-json/ ou admin-ajax.php.
سجلات الخادم : أخطاء PHP "حجم الذاكرة المسموح به..."، "استدعاء دالة غير معرفة..."، "لا يمكن إعادة تعريف..."، "لم يتم العثور على الفئة...".

مخطط التشخيص السريع

عرض	السبب المحتمل	التحقق	الحلول
شاشة بيضاء في كل مكان (الواجهة الأمامية + لوحة التحكم)	خطأ فادح في PHP على مستوى النظام، تحميل تلقائي للملحقات، خطأ في القالب	تفعيل السجلات + إعادة التسمية `plugins`	الحل 1 + 2
إدارة KO، الواجهة الأمامية OK	إضافة الإدارة، مقتطف برمجي متعلق بالإدارة، استهلاك الذاكرة في الصفحات الثقيلة	اختبار /wp-admin + السجلات	الحل 2 + 3 + 5
تم إيقاف الواجهة الأمامية، والإدارة على ما يرام	السمة، ذاكرة التخزين المؤقت، خطاف الواجهة الأمامية، القالب	تغيير المظهر مؤقتًا	الحل 2 + 4
كتلة محرر / Elementor يُحمّل بلا نهاية	خطأ فادح في REST/AJAX، والأمان، والتخزين المؤقت المكثف	وحدة التحكم + السجلات + الاختبار `/wp-json/`	الحل 1 + 2 + "إذا لم ينجح ذلك أيضاً"
خطأ "حجم الذاكرة المسموح به..."	حد ذاكرة PHP منخفض جدًا	سجلات PHP / debug.log	حل 3
بعد لصق الكود	خطأ في بناء الجملة (;	خطأ في تحليل السجلات	حل 4

لماذا وصلت؟

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

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

الأسباب مرتبة من الأكثر شيوعاً إلى الأقل شيوعاً

إضافة متعارضة (ذاكرة التخزين المؤقت، والأمان، والمنشئ، والمقتطفات) بعد التحديث.
موضوع أو موضوع للأطفال : functions.php قالب معطوب وغير متوافق، تم استدعاء الدالة مبكراً جداً.
حد ذاكرة PHP منخفض جدًا (موقع ثقيل، ووكومرس، إليمينتور، ديفي، استيرادات كبيرة).
عدم توافق PHP (الموقع يعمل على PHP 8.0 أو 7.4، أو كود قديم غير متوافق مع PHP 8.1+).
مخبأ عدواني (المكون الإضافي، ذاكرة التخزين المؤقت للخادم، شبكة توصيل المحتوى) التي تقدم استجابة فارغة/500.
الملفات الفاسدة بعد انقطاع التحديث (بروتوكول نقل الملفات غير المستقر، مساحة القرص ممتلئة).
أذونات الملفات غير صحيح (غير قادر على القراءة، أخطاء صامتة تعتمد على الخادم).
إعادة كتابة القواعد (الروابط الدائمة) معطلة: أقل شيوعًا بالنسبة لعطل WSOD الكلي، ولكنها متكررة بالنسبة لأعطال 404/500 على طرق معينة.

المتطلبات الأساسية قبل البدء

حماية : الملفات + قاعدة البيانات. إذا لم تكن لديك أداة، فاطلب من مزود خدمة الاستضافة لقطة، أو قم بتصدير قاعدة البيانات عبر phpMyAdmin.
لا تقم بتعديل نواة ووردبريس (wp-includes, wp-adminلا يمكنك إصلاح شاشة الموت البيضاء عن طريق "تعديل" النظام الأساسي.
وصول : من الأفضل استخدام FTP/SFTP بالإضافة إلى الوصول إلى لوحة التحكم الخاصة بالاستضافة (السجلات) والوصول إلى قاعدة البيانات (phpMyAdmin) إذا لزم الأمر.
إصدارات يُنصح باستخدام ووردبريس 6.9.4 و PHP 8.1 أو أحدث. استخدام إصدار أقدم من PHP يزيد من المخاطر.

أدوات مفيدة (مجانية):

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

الحل الأول: قم بتفعيل وضع تصحيح الأخطاء بشكل صحيح وابحث عن الخطأ بالتحديد

إنّ ظهور شاشة الموت البيضاء بدون سجلات ليس إلا مجرد تخمين. هدفك بسيط: الحصول على خط خطأ قابل للاستغلال (ملف + سطر).

أين نتصرف؟ : في الملف wp-config.php في جذر ووردبريس (على نفس مستوى wp-contentاحفظ الملف قبل تعديله.

قبل (معطل / غير كافٍ)

كثيراً ما رأيت هذه الحالة: موقع إلكتروني في شاشة الموت البيضاء، و WP_DEBUG مفقود أو مُهيأ بشكل خاطئ. أحيانًا يكون مُفعلاً ولكن لا توجد سجلاتإذن لا يمكنك رؤية أي شيء.

<?php
// wp-config.php (extrait) - configuration insuffisante
define('WP_DEBUG', false);

بعد (تم التصحيح: تم تمكين السجلات، وتم تعطيل العرض)

في مجال الإنتاج، أوصي بـ مسجل دون عرض أي شيء على الشاشة (لتجنب كشف المسارات والإصدارات والبيانات السرية). يدعم ووردبريس 6.9.4 هذه الميزة بشكل كامل.

<?php
// wp-config.php (extrait)
// Sauvegardez avant de modifier. Ne laissez pas l'affichage d'erreurs en production.

define('WP_DEBUG', true);

// Écrit les erreurs dans wp-content/debug.log
define('WP_DEBUG_LOG', true);

// N'affiche pas les erreurs aux visiteurs (sécurité)
define('WP_DEBUG_DISPLAY', false);

// Désactive l'affichage PHP direct si le serveur le permet
@ini_set('display_errors', '0');

لماذا يحل هذا المشكلة؟ لم تُصلح المشكلة تمامًا بعد، لكنك حددت السبب الجذري أخيرًا. في 80% من حالات شاشة الموت البيضاء، يشير خط الخطأ مباشرةً إلى الإضافة/القالب/الملف المعيب.

أين يمكن قراءة الخطأ

ملف ووردبريس : wp-content/debug.log
سجلات الخادم : ملف "error_log" في PHP الموجود في لوحة تحكم الاستضافة (غالباً ما يكون أكثر اكتمالاً)

أمثلة على الأخطاء المفيدة (الواقعية):

PHP Fatal error:  Uncaught Error: Call to undefined function my_custom_function()
in /home/site/public_html/wp-content/themes/mon-theme-enfant/functions.php:87

PHP Parse error: syntax error, unexpected token "else"
in /wp-content/plugins/mon-plugin/mon-plugin.php on line 214

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 4096 bytes)
in /wp-includes/class-wpdb.php on line ...

شروحات بسيطة (مصطلحات)

خطأ فادح حدث خطأ حرج. توقف PHP عن كل شيء.
تحليل خطأ خطأ في بناء الجملة (غالباً ما يكون ; مفقود، قوس إضافي، قوس منسي).
خطأ غير معالج : خطأ غير معالج (دالة غير موجودة، فئة غير محملة، إلخ).

المصادر الرسمية:

الحل الثاني: عزل تعارض الإضافات/القوالب دون تعطيل الموقع

يُعدّ تعارض الإضافة/السمة الحالة الأولى. تكمن المشكلة في تعطيلها "عشوائيًا" مما يزيد الأمور سوءًا. هنا، نقوم بعزل المشكلة تمامًا.

طريقتان : مع إمكانية الوصول الإداري (فحص الحالة) أو بدون إمكانية الوصول الإداري (FTP/SFTP).

الطريقة أ (موصى بها إذا كان لديك صلاحيات المسؤول): فحص الحالة في وضع استكشاف الأخطاء وإصلاحها

أين نتصرف؟ : في لوحة التحكم، الإضافات > إضافة، قم بتثبيت "فحص الصحة واستكشاف الأخطاء وإصلاحها".

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

مصدر: فحص الصحة واستكشاف الأخطاء وإصلاحها

الطريقة الثانية (بدون صلاحيات المسؤول): تعطيل جميع الإضافات عبر بروتوكول نقل الملفات (FTP).

أين نتصرف؟ عبر بروتوكول نقل الملفات (FTP/SFTP)، في wp-content/.

أعد تسمية المجلد plugins en plugins.offيقوم ووردبريس تلقائيًا بتعطيل جميع الإضافات لأنه لم يعد بإمكانه العثور عليها.

# Ce n'est pas une commande à exécuter sur votre PC.
# C'est l'idée : renommer le dossier via FTP/SFTP.
wp-content/plugins  ->  wp-content/plugins.off

اختبر موقعك:

إذا عاد الموقع للعمل: فهذا أمر جيد البرنامج المساعدقم بتسليمها plugins.off en pluginsثم أعد تسمية المكونات الإضافية واحدة تلو الأخرى (أو استخدم WP-CLI، انظر الحل 5).
إذا ظل الموقع فارغًا: انتقل إلى اختبار القالب.

اختبر القالب (بدون صلاحيات المسؤول)

تنشأ العديد من شاشات العرض التي تظهر على الشاشة من قالب فرعي (خاصةً بعد لصق أجزاء من التعليمات البرمجية). أسرع طريقة لاختبار ذلك هي فرض استخدام قالب افتراضي.

أين نتصرف؟ :

الخيار الأول: إعادة تسمية مجلد القالب النشط في wp-content/themes/ (سيقوم ووردبريس بالتبديل إلى قالب آخر متاح).
الخيار الثاني (الأكثر سلاسة): تغيير القالب عبر قاعدة البيانات (الحل 5، WP-CLI).

نصيحة أستخدمها كثيراً: إذا كان لديك قالب افتراضي مثبت (على سبيل المثال، Twenty Twenty-Five / Twenty Twenty-Six حسب تثبيتك)، فإن WordPress ينتقل إليه تلقائياً عندما يصبح القالب النشط غير متاح.

التوافق مع أدوات البناء (Divi 5 / Elementor / Avada)

Elementor قد يؤدي تعارض مع مكون إضافي للأمان/التخزين المؤقت إلى تعطيله. wp-json وعرض شاشة فارغة في المحرر.
ديفي 5 لقد رأيتُ حالات ظهور شاشة بيضاء بعد تصغير الملفات بشكل مفرط (باستخدام جافا سكريبت/سي إس إس) أو تحسينها باستخدام أدوات تحسين شاملة. اختبر ذلك بدون إضافة لتحسين الأداء.
فتح : بعض خيارات الأداء + إضافات التخزين المؤقت تضاعف عملية التصغير وتنشئ صفحات فارغة (خاصة في وضع التحرير).

في جميع الحالات: قم أولاً بعزل المشكلة عن طريق تعطيل التخزين المؤقت/الأمان/التحسين، ثم اختبر أداة الإنشاء.

مصدر مفيد: الأسئلة الشائعة حول حل المشكلات (WordPress.org)

الحل الثالث: زيادة ذاكرة PHP وتجنب رسالة "حجم الذاكرة المسموح به..." المزعجة

عند ظهور رسالة "نفدت مساحة الذاكرة المسموح بها"، فإن شاشة الموت البيضاء (WSOD) هي مشكلة تقنية: فقد نفدت ذاكرة PHP. وهذا شائع في المواقع التي تستخدم Elementor/Divi/Avada بالإضافة إلى بعض الإضافات، خاصةً إذا كانت سعة الاستضافة محدودة.

أين يمكنني التحقق؟ : في wp-content/debug.log أو سجلات PHP.

قبل (الأعراض)

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes)
in /wp-includes/class-wp-query.php on line ...

بعد (إصلاح المشكلة من جانب ووردبريس، ثم من جانب الخادم إذا لزم الأمر)

ابدأ بتحديد حجم ذاكرة ووردبريس. هذا لا يتجاوز حدود الخادم، ولكنه يحل العديد من المشاكل.

أين نتصرف؟ : wp-config.php (احفظ أولاً).

<?php
// wp-config.php (extrait)
// Augmente la mémoire disponible pour WordPress.
// Si votre hébergeur impose une limite plus basse, cela ne suffira pas.

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

// Utile pour l'administration (imports, builders, mises à jour)
define('WP_MAX_MEMORY_LIMIT', '512M');

إذا لم يكن ذلك كافيًا، فهذا يعني أن الحد مفروض من قِبل لغة PHP على جانب الخادم. وفقًا لمزود خدمة الاستضافة:

زيادة memory_limit في لوحة الإقامة (مستحسن).
تعديل أ php.ini / .user.ini إذا كان عرضك يسمح بذلك.

مثال (إذا كان مزود خدمة الاستضافة الخاص بك يستخدم .user.ini (في الدليل الرئيسي للموقع):

memory_limit = 512M
max_execution_time = 120

لماذا يتم تصحيحه؟ يتطلب ووردبريس وملحقاته مساحة ذاكرة كافية. عندما تكون هذه المساحة منخفضة جدًا، قد تتوقف عمليات مثل إنشاء ملفات CSS، ومحرر البناء، أو مساحة تخزين كبيرة. WP_Query تسبب في حادث تحطم.

كود المصدر بلغة PHP: memory_limit (php.net)

الحل الرابع: إصلاح جزء الكود المعطل (functions.php) وتأمينه

الحالة التي أراها طوال الوقت: مقتطف يتم نسخه/لصقه في functions.php إذا كانت الفاصلة أو الفاصلة المنقوطة مفقودة من القالب الفرعي، فسيتعطل الموقع بأكمله.

أين نتصرف؟ : wp-content/themes/votre-theme-enfant/functions.php (أو القالب النشط إذا لم يكن لديك قالب فرعي). استخدم بروتوكول SFTP/FTP إذا تعذر الوصول إلى واجهة الإدارة.

قبل (معطل: خطأ في بناء الجملة)

مثال واقعي: تمت إضافة خطاف (فعل)، ولكن القوس مفقود.

<?php
// functions.php (mauvais exemple)
// Objectif : ajouter un message dans le footer.
// Problème : parenthèse manquante => Parse error => WSOD

add_action('wp_footer', function () {
	echo '<p>Hello</p>';
};

بعد (مصحح + أكثر متانة)

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

<?php
// functions.php (exemple corrigé)
// Sauvegardez avant de modifier. Une erreur ici peut casser tout le site.

function bpcab_afficher_message_footer() : void {
	// Ne fait rien dans l'administration
	if ( is_admin() ) {
		return;
	}

	echo '<p>Hello</p>';
}

add_action( 'wp_footer', 'bpcab_afficher_message_footer', 10 );

لماذا يتم تصحيحه؟ يمنع خطأ في تحليل الكود لغة PHP من تحميل الملف. بتصحيح الصيغة، يستطيع ووردبريس إعادة تهيئة القالب.

مثال كلاسيكي آخر: استدعاء الدالة مبكراً جداً (خطاف غير مناسب)

تعريف سريع: أ صنارة صيد هو "خطاف" في ووردبريس. عمل ينفذ التعليمات البرمجية في وقت محدد. مرشحات يقوم بتعديل قيمة (ويجب أن يعيدها).

خطأ شائع: استدعاء دالة غير متاحة بعد.

قبل (مكسور)

<?php
// functions.php (mauvais exemple)
// Problème : wp_get_environment_type() est OK, mais certains codes appellent des fonctions
// de plugin avant que le plugin soit chargé (fatal "Call to undefined function").

ma_fonction_de_plugin_qui_n_est_pas_chargee();

بعد (صحيح: انتظر اللحظة المناسبة)

<?php
// functions.php (exemple corrigé)
// On attend que tous les plugins soient chargés avant d'appeler une fonction de plugin.

function bpcab_appeler_fonction_plugin_apres_chargement() : void {
	if ( function_exists( 'ma_fonction_de_plugin_qui_n_est_pas_chargee' ) ) {
		ma_fonction_de_plugin_qui_n_est_pas_chargee();
	}
}

add_action( 'plugins_loaded', 'bpcab_appeler_fonction_plugin_apres_chargement', 10 );

حسب تجربتي، هذا الأمر البسيط function_exists() يمنع هذا العديد من حالات الشاشة البيضاء بعد تعطيل أحد المكونات الإضافية "عن طريق الخطأ".

روابط المصدر: الخطافات (developer.wordpress.org)

الحل الخامس: استعادة صلاحيات المسؤول في حالة حدوث عطل فادح (وضع الاسترداد، إضافة MU، واجهة سطر أوامر ووردبريس)

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

الخيار أ: وضع استعادة ووردبريس (رسالة بريد إلكتروني "خطأ حرج")

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

إذا لم تستلم البريد الإلكتروني:

تحقق من مجلد الرسائل غير المرغوب فيها.
تأكد من أن الموقع يمكنه إرسال رسائل البريد الإلكتروني (غالباً ما يتم حظر ذلك لدى بعض مزودي خدمات الاستضافة).
انتقل إلى الخيارين ب/ج.

مصدر: الأخطاء الفادحة وكيفية استعادتها (وثائق ووردبريس)

الخيار ب: إنشاء نسخة احتياطية من إضافة MU (تعطيل الإضافة المعيبة)

Un إضافة MU (يجب استخدامه) هو إضافة يتم تحميلها تلقائيًا من wp-content/mu-plugins/إنه مفيد للغاية في استكشاف الأخطاء وإصلاحها لأنه يشحن بسرعة.

أين نتصرف؟ : إنشاء المجلد wp-content/mu-plugins/ إذا لم يكن موجودًا، فأضف ملفًا wsod-rescue.php.

مثال: تعطيل مكون إضافي تم تحديده في السجلات تلقائيًا (استبدال الرابط).

<?php
/**
 * Plugin Name: WSOD Rescue (dépannage)
 * Description: Désactive un plugin problématique pour récupérer l'accès. À supprimer après usage.
 */

// Sécurité : empêche l'accès direct
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

function bpcab_wsod_rescue_desactiver_plugin() : void {
	// Remplacez par le chemin du plugin (dossier/fichier principal)
	$plugin_cible = 'mon-plugin/mon-plugin.php';

	// On évite d'appeler des fonctions non chargées trop tôt
	if ( ! function_exists( 'is_plugin_active' ) ) {
		require_once ABSPATH . 'wp-admin/includes/plugin.php';
	}

	if ( function_exists( 'deactivate_plugins' ) ) {
		deactivate_plugins( array( $plugin_cible ), true );
	}
}

// admin_init est un bon compromis : l'admin charge, et les API plugins sont là.
add_action( 'admin_init', 'bpcab_wsod_rescue_desactiver_plugin' );

لماذا يتم تصحيحه؟ : أنت تجبر على تعطيل إضافة تتسبب في تعطل لوحة التحكم قبل أن تتمكن من النقر على أي شيء.

انتباه قم بإزالة هذا المكون الإضافي لـ MU بعد استكشاف الأخطاء وإصلاحها، وإلا فقد تنسى أنه لا يزال يعطل شيئًا ما.

الخيار ج: WP-CLI (الطريقة الأنظف عند توفرها)

إذا كان مزود الاستضافة الخاص بك يقدم WP-CLI، فيمكنك تعطيل أحد المكونات الإضافية أو تغيير القالب دون تحميل واجهة الويب.

أين نتصرف؟ : طرفية SSH (أو أداة "الطرفية" في اللوحة).

# Vérifier que WP-CLI voit l'installation
wp core version

# Désactiver tous les plugins (diagnostic)
wp plugin deactivate --all

# Réactiver un plugin à la fois
wp plugin activate query-monitor

# Changer de thème (remplacez par un thème installé)
wp theme activate twentytwentyfive

بحسب تجربتي، يوفر لك WP-CLI قدراً هائلاً من الوقت عندما تمنع شاشة الموت البيضاء (WSOD) تحميل أي صفحة.

عمليات التحقق بعد التصحيح

الواجهة الأمامية : تحميل الصفحة الرئيسية + 2-3 صفحات داخلية + صفحة "ثقيلة" (اتصل بنا، متجر، أداة إنشاء الصفحات المقصودة).
إداري : انتقل إلى الإضافات، المظهر، وصفحة المُنشئ (Elementor/Divi/Avada) إذا كنت تستخدمه.
REST API : امتحان https://votre-site.tld/wp-json/أنت بحاجة إلى الحصول على بيانات JSON، وليس خطأ 500.
وحدة تحكم المتصفح اضغط F12 > وحدة التحكم + الشبكة، وتحقق من عدم وجود الخطأ 500. wp-json et admin-ajax.php.
سجلات أعد القراءة wp-content/debug.logقد تبقى بعض التحذيرات، ولكن يجب ألا تظهر لك بعد الآن أي رسائل "خطأ فادح".

بمجرد استقرار النظام، تذكر إعادة ضبط إعدادات تصحيح الأخطاء المناسبة:

احتفظ WP_DEBUG_LOG إذا كنت تقوم بالمراقبة، ولكن تجنب تراكم ملف ضخم (تدوير من جانب الخادم).
لا تدع WP_DEBUG_DISPLAY à true في موقع عام.

إذا لم ينجح ذلك أيضاً

عندما لا تكفي الحلول الخمسة المذكورة أعلاه، فغالبًا ما تكون المشكلة من جانب الخادم، أو سلسلة من الأسباب (ذاكرة التخزين المؤقت + الإضافات + PHP). إليك إجراءً أستخدمه في مواقع العملاء.

مسح جميع ذاكرات التخزين المؤقت :
- إضافة التخزين المؤقت (WP Rocket، LiteSpeed Cache، إلخ).
- ذاكرة التخزين المؤقت للخادم (Varnish، Nginx fastcgi_cache، LiteSpeed) عبر لوحة الاستضافة.
- شبكة توصيل المحتوى (Cloudflare): حذف.
- ذاكرة التخزين المؤقت للمتصفح: تم اختبارها في وضع التصفح الخاص.
تأكد من إصدار PHP قم بالترقية إلى PHP 8.1 أو 8.2 أو 8.3 حسب دعم مزود الاستضافة. قد لا تعمل التعليمات البرمجية القديمة مع PHP 8.1 والإصدارات الأحدث؛ وقد ترفض التعليمات البرمجية الحديثة PHP القديمة جدًا.
تحقق من سجلات الخادم (ليس فقط) debug.log): أحيانًا يكون الخطأ عبارة عن خطأ في تجزئة الذاكرة، أو مهلة زمنية، أو وحدة مفقودة.
جرب ذلك بدون ملف .htaccess (أباتشي):
- إعادة تسمية .htaccess en .htaccess.off (مؤقتا).
- إذا عاد الموقع، فأعد إنشاء الروابط الدائمة بعد ذلك (المسؤول > الإعدادات > الروابط الدائمة > حفظ).
تعطيل تحسين جافا سكريبت/سي إس إس (التصغير، الدمج، التأجيل): لقد رأيت صفحات "فارغة" كانت في الواقع عبارة عن HTML محملة، ولكن ملف JS حرج معطل منع أداة الإنشاء من العرض.
تحقق من أذونات الملفات :
- الملفات: غالباً 755
- الملفات: غالباً 644
تختلف القيم الدقيقة باختلاف مزود خدمة الاستضافة، ولكن يوجد مجلد في 000 أو قد يكون المالك غير المناسب خلق سلوك غريب.
أعد تثبيت نظام ووردبريس الأساسي (بدون لمس) wp-content) إذا كنت تشك في وجود ملفات تالفة:
- قم بتنزيل ووردبريس من wordpress.org/download.
- يستبدل wp-admin et wp-includes + ملفات الجذر (باستثناء wp-config.php et wp-content).
استخدم مراقب الاستعلامات بمجرد أن يصبح الموقع متاحًا مرة أخرى: سترى الأخطاء، واستدعاءات REST، والخطافات، وغالبًا المكون الإضافي المسؤول.

إذا كنت تواجه شاشة بيضاء فقط على عنوان URL محدد، فتحقق أيضًا مما يلي:

رمز مختصر يستدعي دالة غير موجودة.
قالب صفحة (منشئ) يؤدي إلى طلب ضخم.
حلقة لا نهائية (إعادة توجيه) مخفية بواسطة ذاكرة تخزين مؤقتة/شبكة توصيل محتوى.

الأخطاء الشائعة والمزالق

عرض	السبب المحتمل	الخطأ الشائع الملحوظ	يوصى بالحل
شاشة الموت البيضاء مباشرة بعد لصق مقتطف من التعليمات البرمجية	تحليل خطأ	تم لصق الكود في الملف الخطأ (ملف الإضافة مقابل ملف القالب)، أو `;` نسي	الحل الرابع (الصيغة الصحيحة عبر بروتوكول نقل الملفات FTP)
شاشة الموت البيضاء بعد تحديث الملحق	الصراع / عدم التوافق	أعد تنشيط "كل شيء" دفعة واحدة دون عزله	الحل الثاني (تعطيل كل شيء، ثم إعادة تنشيطه واحداً تلو الآخر)
إدارة KO، الواجهة الأمامية OK	إضافة الذاكرة / الإدارة	اختبار الشاشة الرئيسية فقط والافتراض بأن "المشكلة قد تم حلها"	الحل الثالث + عمليات التحقق الإدارية
لم يعد يتم تحميل Elementor/Divi	REST/AJAX في 500	انسَ أمر وحدة تحكم المتصفح وطلبات الشبكة	الحل 1 + التحقق `/wp-json/`
شاشة الموت العشوائية	ذاكرة التخزين المؤقت/شبكة توصيل المحتوى، مهلة الانتظار، الموارد	لا تقم بمسح ذاكرة التخزين المؤقت لخادم Cloudflare	إجراء "إذا لم ينجح ذلك بعد"
شاشة الموت البيضاء بعد "التحسين"	تصغير مفرط العدوانية	فعّل خاصية الدمج والتأجيل في كل مكان دون استثناءات.	قم بتعطيل تحسين JS/CSS، ثم أعد تمكينه تدريجياً.
شاشة الموت البيضاء بعد تغيير PHP	كود قديم غير متوافق مع PHP 8.1+	اتباعًا لدرس تعليمي من عام 2018 يتضمن وظائف/أساليب قديمة	قم بتحديث الإضافات/القالب، وأصلح الكود، واستخدم إصدار PHP 8.1 أو أحدث.

بديل / متغير

طريقة بدون كتابة أكواد: إضافة إدارة المقاطع البرمجية (والتراجع)

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

أنا لا أجبرك على استخدام إضافة معينة، ولكن ابحث عن الميزات:

تفعيل/تعطيل جزء واحد من التعليمات البرمجية
التنفيذ المشروط (واجهة المستخدم/إدارة)
التاريخ / التراجع

طريقة أكثر تطوراً: رصد الوفيات والتراجعات

بالنسبة للمواقع الإلكترونية الاحترافية، قم بتنفيذ ما يلي:

بيئة تجريبية (ما قبل الإنتاج) وسير عمل النشر.
مراقبة الأخطاء (سجلات مركزية، تنبيهات).
الاختبارات الأساسية بعد التحديث (الواجهة الأمامية + لوحة التحكم + صفحة الدفع إذا كان متجرًا إلكترونيًا).

تجنب هذه المشكلة في المستقبل

لن تتمكن أبدًا من القضاء على 100% من المخاطر، ولكن يمكنك تقليل حالات فقدان الوعي بشكل كبير.

1) قم بإجراء التغييرات في إضافة "مخصصة" (وليس في القالب).

يتغير القالب، وتبقى الإضافة المخصصة. بالنسبة للمقاطع البرمجية الخاصة بمجال معين، أفضل استخدام إضافة مصغرة.

أين نتصرف؟ : يخلق wp-content/plugins/mon-site-custom/mon-site-custom.phpثم قم بتفعيله.

<?php
/**
 * Plugin Name: Mon site - Custom
 * Description: Snippets stables du site (WordPress 6.9.4+, PHP 8.1+).
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'init', function () : void {
	// Exemple : point d'entrée sûr (init) pour vos personnalisations.
} );

2) استخدم وسائل الحماية (function_exists, class_exists)

إذا كان الكود الخاص بك يعتمد على إضافة (مثل Elementor أو WooCommerce)، فقم بحماية استدعاء هذه الإضافة. هذا يمنع حدوث خطأ الشاشة البيضاء في حال تعطيل الإضافة.

<?php
// Exemple de garde-fou
if ( class_exists( 'WooCommerce' ) ) {
	// Code WooCommerce ici
}

3) التحديث بذكاء

قم بإجراء التحديثات في بيئة الاختبار، ثم في بيئة الإنتاج.
تجنب تحديث 15 إضافة في وقت واحد بدون نقطة استعادة.
قم بمراقبة سجلات التغييرات الخاصة بالمكونات الإضافية الهامة (ذاكرة التخزين المؤقت، والأمان، والمنشئ).

4) حافظ على ميزانية واقعية للخادم

PHP 8.1+ (ويفضل 8.2/8.3 حسب مزود الاستضافة والتوافق)
يُعدّ حد الذاكرة مناسبًا (غالبًا ما يكون الحد الأدنى 256 ميجابايت، و512 ميجابايت مناسبًا للمطورين).
مساحة تخزين كافية (لقد رأيت تحديثات تتوقف بسبب امتلاء القرص عدة مرات).

الموارد

أسئلة fréquentes

موقعي الإلكتروني أبيض اللون، ولكن هذا خاص بي فقط. لماذا؟

غالباً ما تكون المشكلة متعلقة بذاكرة التخزين المؤقت (المتصفح/شبكة توصيل المحتوى) أو بجلسة المستخدم/ملفات تعريف الارتباط. جرّب التصفح في وضع التصفح الخاص، ثم امسح ذاكرة التخزين المؤقت للملحق وشبكة توصيل المحتوى. تأكد أيضاً من تسجيل دخولك: بعض الأخطاء تظهر فقط للمسؤولين (شريط الإدارة، تحرير الوحدات).

ليس لدي ملف debug.log، هل هذا طبيعي؟

نعم، إذا لم يتم تسجيل أي أخطاء، أو إذا wp-content غير قابل للكتابة. تحقق من الأذونات، واطلع على سجلات PHP على جانب الاستضافة (غالباً ما تكون أكثر موثوقية).

هل يمكنني ترك خاصية WP_DEBUG مفعلة بشكل دائم؟

يمكنك المغادرة WP_DEBUG à true إذا لم تظهر الأخطاء على الشاشة (WP_DEBUG_DISPLAY à falseوإذا كنت تدير السجلات، فإن عرض الأخطاء على موقع عام يشكل خطراً أمنياً.

لماذا يمكن أن يتسبب مكون إضافي للتخزين المؤقت في ظهور شاشة الموت البيضاء؟

لأنها قد تُصغّر/تُدمج البرامج النصية الهامة، أو تُقدّم استجابة مُخزّنة فارغة/غير صحيحة. في أدوات إنشاء المواقع (مثل Divi 5 وElementor وAvada)، غالبًا ما يؤدي التحسين المفرط إلى تعطيل المُحرّر قبل تعطيل واجهة المستخدم.

لقد عطلت جميع الإضافات، لكن الصفحة لا تزال فارغة. ماذا أفعل الآن؟

اختبر السمة (الحل 2)، ثم الذاكرة (الحل 3)، ثم أعد التسمية مؤقتًا .htaccess (أباتشي). إذا لم يتغير شيء، فتحقق من سجلات الخادم: من المحتمل أنك تواجه مشكلة في PHP/الخادم (انقطاع الاتصال، وحدة مفقودة، ملف تالف).

هل يمكن أن يؤدي تغيير اسم مجلد الإضافات إلى تعطيل موقعي؟

هذا يُعطّل كل شيء، لذا تختفي بعض الميزات (النماذج، تحسين محركات البحث، التخزين المؤقت). لكن يمكن التراجع عن هذا الإجراء وهو فعّال للغاية لاستعادة الوصول. ما عليك سوى إعادة تسميته. plugins.off en plugins يوجد.

ماذا تفعل إذا ظهرت شاشة الموت البيضاء (WSOD) بعد تحديث ووردبريس إلى الإصدار 6.9.4؟

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

يعرض برنامج Elementor شاشة فارغة، لكن الموقع العام يعمل بشكل صحيح. أين يجب أن أبحث؟

انظر إلى وحدة التحكم (F12) وعلامة تبويب الشبكة: إذا /wp-json/ إذا أعاد طلب AJAX خطأ 500، فهذا خطأ فادح من جانب الخادم. فعّل التسجيل وعطّل الأمان/التخزين المؤقت مؤقتًا.

لم يعد تطبيق Divi 5 يعمل بعد التحديث. ما الذي يجب عليّ فعله أولاً؟

عطّل خاصية التصغير/الدمج/التأجيل، وامسح جميع ذاكرات التخزين المؤقت، ثم اختبر. بعد ذلك، أعد تفعيل التحسين تدريجيًا مع استثناءات. غالبًا ما تكون شاشات العرض المرئية (WSODs) التي يعرضها المُنشئ عبارة عن أكواد جافا سكريبت معطوبة، وليست أكواد HTML فارغة حقيقية.

متى يجب عليك الاتصال بمزود خدمة الاستضافة؟

بمجرد أن تشك في وجود قيود على الخادم (الذاكرة/وحدة المعالجة المركزية)، أو وحدة مفقودة، أو جدار حماية تطبيقات الويب (WAF) يعيق العملية، أو إذا أظهرت السجلات أخطاءً لا علاقة لها بـ WordPress، فأعطهم الوقت المحدد ومقتطف السجل: فهذا يسرع الأمور بشكل كبير.