شاشة بيضاء في ووردبريس: 5 حلول سهلة

من قبل | WordPress

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

المشكلة

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

HTTP ERROR 500

أو، إذا كانت الاستضافة تعرض أخطاء PHP (وهو أمر نادر الحدوث في بيئة الإنتاج)، فإليك مثال على ذلك:

Fatal error: Uncaught Error: Call to undefined function ... in /home/.../wp-content/themes/.../functions.php:123

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

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

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

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

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

ملخص سريع

  • لا تخمن : قم بتمكين تصحيح الأخطاء واقرأ الخطأ (الحل 1).
  • عزل : قم بتعطيل جميع الإضافات وقم بالعودة إلى المظهر الافتراضي (الحل 2).
  • تحقق من الذاكرة تنشأ العديد من حالات WSOD من نفدت مساحة الذاكرة المسموح بها (الحل 3).
  • قصاصات : فاصلة منقوطة مفقودة في functions.php يكفي لتبييض كل شيء (الحل 4).
  • مخبأ : يمكنك "إصلاح" الموقع دون رؤيته إذا كان OPcache/CDN يقدم الإصدار القديم (الحل 5).

الأعراض

لا يقتصر ظهور شاشة الموت على كونها "مجرد صفحة بيضاء". إليك العلامات الملموسة التي يجب البحث عنها (وما تشير إليه).

  • صفحة فارغة كاملة (الأمام) ولكن / الفسفور الابيض الادارية يعمل: غالباً ما تكون المشكلة في السمة، أو القالب، أو الرمز المختصر، أو ذاكرة التخزين المؤقت للصفحة التالفة.
  • / الفسفور الابيض الادارية الأبيض أيضًا: غالبًا ما يكون خطأً فادحًا في PHP (إضافة، قالب، مقتطف) أو حدًا للذاكرة.
  • خطأ 500 في المتصفح: غالبًا ما يكون خطأً فادحًا في PHP، أو تكوين الخادم، أو وحدة (OPcache) تقدم رمزًا قديمًا.
  • لم يعد يتم تحميل محرر Elementor/Divi/Avada أخطاء REST API/AJAX، مشاكل الذاكرة، تعارضات المكونات الإضافية (الأمان/التخزين المؤقت)، أو أخطاء JS المخفية.
  • يعمل الموقع محليًا لكن ليس في بيئة الإنتاج: اختلافات في إصدار PHP، وامتدادات PHP، وحدود الذاكرة، وذاكرة التخزين المؤقت للخادم، وأذونات الملفات.
  • صفحات معينة فقط : رمز مختصر معطل، طلب كبير جدًا، حلقة لا نهائية، أو صورة/مورد يتسبب في استهلاك الذاكرة بشكل مفرط.

تشخيص سريع من جانب المتصفح: افتح وحدة التحكم (F12) وانظر:

  • كنسولات : أخطاء جافا سكريبت (مفيدة بشكل خاص للمطورين).
  • الانرنيت استعلامات XHR إلى /wp-json/ (واجهة برمجة تطبيقات REST) ​​أو admin-ajax.php في 500/403.

لماذا وصلت؟

شرح مبسط (للمبتدئين)

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

لذلك، نادراً ما يكون نظام WSOD "غامضاً". بل هو في الغالب:

  • un خطأ برمجي (إضافة/قالب/مقتطف برمجي)،
  • un نقص الموارد (الذاكرة/الوقت)،
  • أو مخبأ والذي يُظهر لك نسخة معطوبة على الرغم من أنك قمت بإصلاحها.

شرح فني (مستوى متوسط/محترف)

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

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

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

لمساعدتك في ترتيب الأمور، إليك جدول تشخيصي: "العرض ← الفحص ← الحل".

عرض السبب المحتمل التحقق الحلول
شاشة بيضاء في كل مكان خطأ فادح في PHP تفعيل WP_DEBUG + القراءة debug.log الحل 1 + 2
خطأ 500 خطأ فادح في PHP / حد الذاكرة / ذاكرة التخزين المؤقت للخادم سجلات الخادم + debug.log الحل 1 + 3 + 5
موافق من الإدارة، واجهة بيضاء القالب / الرمز المختصر / ذاكرة التخزين المؤقت للصفحة قم بتغيير المظهر مؤقتًا + امسح ذاكرة التخزين المؤقت الحل 2 + 5
لم يعد Elementor/Divi يفتح المحرر خطأ في REST/AJAX، الذاكرة وحدة التحكم + الشبكة (XHR 500/403) الحل الثالث + "إذا لم ينجح ذلك أيضاً"
شاشة الموت البيضاء بعد إضافة جزء من التعليمات البرمجية خطأ في بناء الجملة / حدث خطأ في الربط مبكراً آخر ملف تم تعديله، سجلات حل 4

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

احفظ الملف قبل إجراء أي تغييرات. إذا كنت بحاجة إلى العمل مع أي ملفات، فقم على الأقل بعمل نسخة من:

  • wp-config.php
  • سجل wp-content (أو على الأقل themes et plugins)

المتطلبات التقنية الموصى بها (ووردبريس 6.9.4 اعتبارًا من أبريل 2026):

  • PHP 8.1 + (الحد الأدنى الموصى به). إذا كان مستوى النظام لديك أقل من ذلك، فإنك تزيد بشكل كبير من خطر وجود أخطاء وثغرات أمنية.
  • الولوج إلى FTP / SFTP أو إلى مدير الملفات الخاص بمزود خدمة الاستضافة.
  • من الأفضل أن انطلاق (موقع تجريبي). يقدم العديد من مزودي خدمات الاستضافة هذه الميزة بنقرة واحدة.

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

قاعدة ذهبية : لا تقم بتعديل النواة (ملفات ووردبريس في wp-includes / wp-adminيتم إجراء التصحيح في إضافة أو قالب فرعي أو في الإعدادات.

الحل الأول: تفعيل وضع تصحيح الأخطاء بشكل صحيح (والعثور على الخطأ المحدد)

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

أين يجب التدخل؟ في الملف wp-config.php، في جذر ووردبريس (على نفس مستوى wp-content).

احفظ التغييرات قبل إجرائها. خطأ مطبعي في wp-config.php قد يؤدي ذلك إلى عدم توفر الموقع.

قبل (التكوين النموذجي الذي يخفي كل شيء)

العديد من المواقع لا تحتوي على أي شيء، أو تحتوي على نظام تصحيح أخطاء غير مكتمل:

<?php
// ... contenu existant ...

/* C'est tout : aucune trace d'erreur exploitable. */

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

أضف هذه الثوابت (أو عدّلها). ضعها في مكانها. قبل لا يجني /* That's all, stop editing! */ إذا كان موجودًا في ملفك.

<?php
// ... contenu existant ...

/**
 * Debug WordPress (WordPress 6.9.4+ / PHP 8.1+)
 * Objectif : écrire les erreurs dans wp-content/debug.log sans les afficher aux visiteurs.
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// Évite d'afficher des erreurs PHP directement dans le HTML.
@ini_set( 'display_errors', '0' );

ثم:

  1. أعد تحميل الصفحة الفارغة (الصفحة الأمامية أو صفحة الإدارة).
  2. فتح wp-content/debug.log وابحث عن الخطأ الأخير.

أمثلة على الأخطاء التي قد تراها:

PHP Fatal error:  Uncaught Error: Call to undefined function my_plugin_helper() in /wp-content/plugins/mon-plugin/mon-plugin.php:88
PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in /wp-includes/class-wpdb.php on line ...

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

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

المصدر الرسمي: تصحيح أخطاء ووردبريس

الحل الثاني: عزل تعارض بين الإضافة/القالب (طريقة المبتدئين + طريقة "بدون صلاحيات المسؤول")

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

الطريقة أ (للمبتدئين): من لوحة التحكم الإدارية إذا كان لديك صلاحية الوصول

  1. اذهب ملحقات> ملحقات مثبتة.
  2. حدد الكل، ثم عطل.
  3. اختبر الموقع.
  4. اعادة تفعيل تمديد واحد في كل مرة إلى أن يتم إعادة إنتاج شاشة الموت البيضاء.

بعد ذلك، قم بالتبديل مؤقتًا إلى المظهر القياسي:

  • المظهر > السمات > تفعيل سمة رسمية (غالباً ما تكون Twenty*).
  • حاول ثانية.

إذا كنت تستخدم Divi 5 أو Elementor أو Avada، فإن هذه القوالب/أدوات الإنشاء تضيف الكثير من التعليمات البرمجية. ومن الشائع حدوث تعارض مع إضافات التخزين المؤقت/الأمان. يُعد اختبار "القالب الافتراضي + تعطيل الإضافات" أسرع طريقة لإيقاف هذه الحلقة المفرغة.

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

Si /wp-admin إذا كان اللون أبيض، استخدم بروتوكول نقل الملفات (FTP/SFTP).

الخطوة الأولى: تعطيل جميع الإضافات دفعة واحدة

أين يجب التدخل؟ أعد تسمية المجلد wp-content/plugins en plugins.offسيعتبر ووردبريس الإضافات غير موجودة وسيقوم بتعطيلها.

# Exemple (le nom exact dépend de votre outil FTP)
wp-content/plugins  →  wp-content/plugins.off

اختبر الموقع. إذا عادت المشكلة، فهذا يعني أن الخلل يكمن في الإضافة (أو الإضافات). ثم أعد تثبيتها.

wp-content/plugins.off  →  wp-content/plugins

ثم، في الداخل pluginsأعد تسمية المجلدات واحداً تلو الآخر (على سبيل المثال، elementor → elementor.off) للعثور على الجاني.

الخطوة الثانية: فرض استخدام سمة احتياطية في حال تعطل السمة الحالية

إذا كان الموقع لا يزال أبيض اللون مع إيقاف تشغيل الإضافات، فإن القالب (أو القالب الفرعي) مشكوك فيه.

خيار بسيط : أعد تسمية مجلد القالب النشط (أو القالب الفرعي). سيقوم ووردبريس بالتبديل إلى قالب آخر متاح.

wp-content/themes/mon-theme-enfant  →  wp-content/themes/mon-theme-enfant.off

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

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

الحل الثالث: إصلاح مشكلة تعطل النظام بسبب عدم كفاية الذاكرة (PHP/WordPress)

يُعدّ نقص الذاكرة مشكلة شائعة في المواقع التي تستخدم Elementor/Divi/Avada مع WooCommerce بالإضافة إلى إضافات الأمان والتخزين المؤقت. وتظهر أعراض هذه المشكلة أحيانًا على شكل شاشة بيضاء، وأحيانًا أخرى على شكل خطأ 500، وأحيانًا أخرى على شكل رفض تحميل المحرر.

الرسالة النموذجية في debug.log :

PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate ...)

الخطوة الأولى: زيادة الذاكرة على جانب ووردبريس (بسرعة)

أين يجب التدخل؟ في wp-config.php، قبل "إيقاف التحرير".

قبل (بدون حد صريح)

<?php
// ...

بعد (يطلب من ووردبريس استخدام المزيد من الذاكرة)

<?php
// ...

/**
 * Augmente la mémoire pour WordPress.
 * Attention : si PHP a une limite plus basse, cela ne suffira pas.
 */
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour l'admin et certaines tâches lourdes.

لماذا يعمل: WP_MEMORY_LIMIT يُحدد هذا الخيار حجم الذاكرة المستهدفة لـ WordPress. ولكن إذا فرض خادمك حدًا أدنى، فلن يتمكن WordPress من تجاوزه.

الخطوة الثانية: زيادة تخصيص الذاكرة على جانب PHP (غالباً ما يكون ذلك ضرورياً)

يتم ذلك عبر ما يلي، وذلك بحسب مزود خدمة الاستضافة الخاص بك:

  • لجنة الإقامة (موصى بها)،
  • ملف php.ini ou .user.ini,
  • أو تكوين PHP-FPM (إذا كنت تدير الخادم).

مثال (ملف) .user.ini (في العديد من خدمات الاستضافة المشتركة):

memory_limit = 512M
max_execution_time = 120

المرجع الرسمي للغة PHP (memory_limit): حد الذاكرة php.net

ما أقوم باختباره بعد زيادة الذاكرة

  • جارٍ تحميل صفحة فارغة.
  • فتح المحرر (Elementor/Divi/Avada).
  • في حال استخدام WooCommerce: أضف إلى السلة، وادفع، وافتح صفحة المنتج.

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

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

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

شروط:

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

الحالة أ: تمت إضافة الكود إلى ملف functions.php (قالب فرعي)

أين يجب التدخل؟ wp-content/themes/VOTRE-THEME-ENFANT/functions.php

خطأ واقعي للغاية: نسيان الفاصلة المنقوطة، أو إغلاق القوس المعقوف.

قبل (مكسور: ينقصه فاصلة منقوطة)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' )
}

بعد (مصحح)

<?php
add_action( 'wp_enqueue_scripts', 'mon_site_styles' );

function mon_site_styles() {
	// Charge une feuille de style
	wp_enqueue_style( 'mon-style', get_stylesheet_directory_uri() . '/style.css' );
}

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

الحالة ب: يستخدم الكود خطافًا مبكرًا جدًا (الدالة "لم يتم تحميلها بعد").

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

قبل (معطل: التنفيذ الفوري مبكراً جداً)

<?php
// Mauvaise idée : ce code s'exécute dès le chargement du fichier.
ma_fonction_qui_depend_de_wordpress();

function ma_fonction_qui_depend_de_wordpress() {
	// Exemple : vous faites des appels à des APIs WordPress non disponibles à cet instant
	update_option( 'test', 'ok' );
}

بعد (مصحح: التنفيذ عبر إجراء)

<?php
/**
 * On utilise une action pour attendre que WordPress soit chargé.
 * Une "action" est un hook qui déclenche votre code à un moment précis.
 */
add_action( 'init', 'ma_fonction_qui_depend_de_wordpress' );

function ma_fonction_qui_depend_de_wordpress() {
	update_option( 'test', 'ok' );
}

لماذا يتم تصحيح ذلك؟ init يتم تشغيله بعد تحميل ووردبريس. هذا يمنع استدعاءات النظام قبل الأوان.

الحالة ج: مقتطف برمجي عبر إضافة (WPCode، مقتطفات برمجية، إلخ).

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

المرجع (الخطافات): developer.wordpress.org/plugins/hooks

الحل الخامس: التخلص من شاشة الموت البيضاء الوهمية الناتجة عن ذاكرة التخزين المؤقت (ذاكرة التخزين المؤقت للصفحات، وشبكة توصيل المحتوى، وذاكرة التخزين المؤقت لـ OP).

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

أرى هذا كثيراً على:

  • المواقع التي تستخدم خدمة Cloudflare (أو أي شبكة توصيل محتوى أخرى)،
  • مزودو خدمات الاستضافة الذين يستخدمون التخزين المؤقت للخادم بشكل مكثف
  • المواقع التي تم تمكين OPcache فيها ثم تعطيلها بشكل غير صحيح بعد النشر.

الخطوة 1: مسح ذاكرة التخزين المؤقت "الظاهرة"

  • قم بمسح ذاكرة التخزين المؤقت للملحقات (LiteSpeed ​​Cache، WP Rocket، W3TC...).
  • قم بمسح ذاكرة التخزين المؤقت لشبكة توصيل المحتوى (Cloudflare: "مسح كل شيء" أو مسح مستهدف).
  • اختبر في وضع التصفح الخاص + عن طريق إضافة مُعامل: ?nocache=1

الخطوة الثانية: OPcache (من جانب الخادم)

إذا كان لديك صلاحية الوصول إلى الخادم، فإن الحل الأمثل هو إعادة تشغيل PHP-FPM (بحسب بيئة التشغيل لديك). مثال (لينكس):

sudo systemctl reload php8.2-fpm

إذا كنت تستخدم استضافة مشتركة، فلن تجد هذا الأمر. في هذه الحالة:

  • ابحث عن خيار "مسح ذاكرة التخزين المؤقت OPcache" في اللوحة.
  • أو اطلب من الدعم مسح ذاكرة التخزين المؤقت لـ OPcache (وهذا غالبًا ما يكون طلبًا قياسيًا).

لماذا يحل هذا المشكلة؟ لأن OPcache يستطيع تخزين نسخة قديمة من ملف PHP في الذاكرة. تقوم بإصلاح الملف... لكن PHP لا يزال يُنفذ النسخة القديمة.

المرجع الرسمي لـ OPcache: php.net OPcache

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

بمجرد عودة الموقع للعمل، أقوم دائمًا بإجراء نفس الاختبارات "الأساسية ولكن الفعالة":

  1. جبهة الصفحة الرئيسية + صفحتان أو ثلاث صفحات داخلية + البحث.
  2. إداري : لوحة التحكم، الإضافات، المظهر، المحرر (إن وجد).
  3. بناة :
    • Elementor: افتح المحرر + احفظ التغيير.
    • Divi 5: افتح أداة إنشاء الصفحات المرئية + تحقق من المعاينة المتجاوبة.
    • أفادا: افتح برنامج Fusion Builder + تحقق من تحرير الحاوية.
  4. أشكال : إرسال نموذج (للاتصال/النشرة الإخبارية).
  5. REST API اختبار سريع عن طريق زيارة /wp-json/ (يجب أن ترى JSON، وليس صفحة فارغة).

ثم:

  • إقرأ مرة أخرى wp-content/debug.log إذا استمر في النمو، فستظل تواجه أخطاء (حتى لو كان الموقع "يعمل").
  • قم بتعطيل وضع التصحيح إذا كنت قد قمت بتمكينه في بيئة الإنتاج (الحل 1).

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

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

1) تحقق من سجلات الخادم (غالباً ما تكون أكثر إفادة من ملف debug.log)

ستجد في لوحة التحكم لدى العديد من مزودي خدمات الاستضافة سجل أخطاء Apache/Nginx. ابحث عن:

  • PHP Fatal error
  • Premature end of script headers
  • Allowed memory size

2) استخدم فحص الحالة الصحية (وضع استكشاف الأخطاء وإصلاحها)

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

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

3) تحقق من إصدار PHP الفعلي

قد يعتقد موقع ويب أنه يعمل بنظام PHP 8.1، بينما قد يعمل نطاق فرعي أو مهمة مجدولة بنظام 7.4 (لقد رأيت ذلك يحدث). تحقق من ذلك.

  • الأدوات > صحة الموقع
  • أو لوحة تحكم مزود خدمة الاستضافة

4) قم بتعطيل إضافات mu مؤقتًا

ال مو الإضافات يتم تحميل (المكونات الإضافية الإلزامية) تلقائيًا من wp-content/mu-pluginsلا تظهر هذه الامتدادات في قائمة الامتدادات القياسية. يستخدم بعض مزودي خدمات الاستضافة ذاكرة تخزين مؤقتة/إجراءات أمنية.

امتحان : إعادة تسمية mu-plugins en mu-plugins.off عبر بروتوكول نقل الملفات (FTP)، ثم قم بالاختبار.

5) الروابط الدائمة / قواعد إعادة الكتابة ("موافقة المسؤول، الصفحات 404/500")

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

الإعدادات> الروابط الثابتة ثم اضغط سجّل (دون تغيير أي شيء).

وثيقة رسمية: WP-CLI (للمحترفين) (مفيد إذا كان لديك وصول SSH، ولكنه اختياري هنا).

6) تحقق من أذونات الملفات (نادر الحدوث، ولكنه حقيقي)

قد تتسبب الصلاحيات المقيدة للغاية في حدوث أخطاء في الخادم. في بيئات لينكس المشتركة، نلاحظ غالبًا ما يلي:

  • عدد الملفات: 755
  • عدد الملفات: 644

إذا كان لدى مزود خدمة الاستضافة الخاص بك توصيات مختلفة، فاتبعها.

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

عرض السبب المحتمل يوصى بالحل
لقد قمت بتفعيل WP_DEBUG ولكن debug.log لا تظهر wp-content غير قابل للكتابة / إعدادات خاطئة / خطأ قبل التحميل تحقق من الأذونات، ثم راجع سجلات الخادم.
شاشة الموت البيضاء مباشرة بعد لصق رمز الفاصلة المنقوطة/القوس مفقودة، تم لصق الكود في المكان الخطأ الحل الرابع (تصحيح المقتطف البرمجي)، ويفضل أن يكون ذلك في إضافة مخصصة
يعمل في وضع التصفح الخاص ولكن ليس "بشكل طبيعي". ذاكرة التخزين المؤقت للمتصفح / الإضافات / شبكة توصيل المحتوى (CDN) الحل الخامس (عمليات التنظيف) + تعطيل تصغير الملفات مؤقتًا
لم يعد Elementor/Divi/Avada يفتح المحرر تم حظر الذاكرة، وREST/AJAX بسبب إجراءات الأمان، وتعارض في المكونات الإضافية. الحل الثالث + فحص وحدة التحكم + تعطيل الملحق الأمني
لقد اتبعت برنامجًا تعليميًا قديمًا كود غير متوافق مع ووردبريس 6.9.4 / PHP 8.1 استبدل هذا الأسلوب بالأسلوب الحالي، واختبره في بيئة تجريبية.
لقد قمت بتعديل القالب الرئيسي فقدان التعديلات عند التحديث، خطر التلف العودة إلى قالب فرعي أو إضافة مخصصة (انظر قسم "تجنب").
تظهر شاشة الموت البيضاء بعد "الإصلاح" لا يزال OPcache/CDN يستخدم الإصدار القديم الحل الخامس (حذف وإعادة تحميل PHP-FPM إن أمكن)

الأخطاء "البشرية" التي أراها في أغلب الأحيان:

  • ألصق مقتطفًا في ملف تالف (على سبيل المثال، في قالب بدلاً من functions.php).
  • نسيان قوس أو فاصلة منقوطة.
  • أربك عمل et مرشحات (مثال: استخدام) add_action بدلا من add_filter).
  • اختبر مباشرة على إنتاج بدون نسخة احتياطية.
  • انسى مسح ذاكرة التخزين المؤقت بعد التصحيح.

بديل / متغير

طريقة بدون كتابة أكواد (موصى بها للمبتدئين)

إذا كان بإمكانك الوصول إلى لوحة التحكم، فقم بتثبيت ما يلي:

هذه هي الطريقة الأكثر أمانًا على موقع إلكتروني: يمكنك إجراء البحث دون الإخلال بتجربة الزائر.

طريقة أكثر تقدماً (للمطورين): النسخ الاحتياطي لملحق mu

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

مكان لصق الكود: إنشاء الملف wp-content/mu-plugins/00-rescue.php (أنشئ المجلد إذا لم يكن موجودًا).

<?php
/**
 * Plugin Name: Rescue minimal
 * Description: Aide au dépannage : loggue des infos minimales si le site plante tôt.
 * Author: Votre Nom
 *
 * Attention : ceci ne remplace pas WP_DEBUG. C'est un filet de sécurité.
 */

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

// Exemple : log simple pour confirmer que WordPress charge bien les mu-plugins.
error_log( '[Rescue] mu-plugin chargé' );

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

المرجع الرسمي حول إضافات mu: developer.wordpress.org/advanced-administration/plugins/mu-plugins

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

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

1) قم بإجراء التعديلات في إضافة مخصصة، وليس في ملف functions.php

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

مكان لصق الكود: يخلق wp-content/plugins/mon-plugin-custom/mon-plugin-custom.phpثم قم بتفعيله.

<?php
/**
 * Plugin Name: Mon plugin custom
 * Description: Snippets stables pour ce site (WordPress 6.9.4+ / PHP 8.1+).
 * Version: 1.0.0
 */

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

/**
 * Exemple : on accroche un code sur une action.
 */
add_action( 'init', function () {
	// Code sûr : exécuté après le chargement de WordPress.
} );

2) تنفيذ خطة مرحلية

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

3) تحقق من توافق PHP 8.1+

قد يتعطل أحد الإضافات غير المُحدَّثة بعد ترقية إصدار PHP. تحقق من التوافق على صفحة الإضافة (wordpress.org) وتابع سجل التغييرات.

4) احتفظ بوصول للطوارئ

  • الوصول الوظيفي إلى SFTP/FTP
  • الوصول إلى لوحة تحكم الاستضافة (السجلات، إصدار PHP، ذاكرة التخزين المؤقت)
  • نسخة احتياطية يومية (يفضل أن تكون خارجية)

5) ذاكرة التخزين المؤقت: وثّق "مسار التطهير" الخاص بك

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

الموارد

أسئلة fréquentes

هل تأتي شاشة الموت البيضاء بالضرورة من إضافة برمجية؟

لا. قد يتسبب كل من القالب، والقالب الفرعي، ومقتطف برمجي، ونقص الذاكرة، أو ذاكرة التخزين المؤقت للخادم في ظهور نفس الأعراض. ​​تبقى أسرع طريقة هي استخدام ملف debug.log مع تعطيل جميع العناصر دفعة واحدة (الحل 1 + 2).

لماذا لا أتلقى أي رسائل خطأ؟

لأن معظم الخوادم تخفي أخطاء PHP في بيئة الإنتاج. هذا أمر طبيعي (لأسباب أمنية). فعّل التسجيل عبر WP_DEBUG_LOG لاسترداد الخطأ دون عرضه للزوار.

هل يمكنني إصلاح هذا بدون استخدام بروتوكول نقل الملفات (FTP)؟

نعم، إذا كان لديك صلاحيات المسؤول: فحص حالة النظام وتعطيل الإضافات غالبًا ما يكون كافيًا. أما إذا لم يكن لديك صلاحيات المسؤول، فإن الوصول إلى الملفات (عبر بروتوكول نقل الملفات FTP/SFTP) هو الطريقة الأسهل.

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

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

يعرض برنامج Elementor شاشة بيضاء في المحرر: هل هذا هو نفسه؟

نعم في أغلب الأحيان، ولكن قد تكمن المشكلة في جانب واجهة برمجة تطبيقات REST/AJAX. تحقق من علامة تبويب الشبكة: إذا كانت الطلبات إلى /wp-json/ ou admin-ajax.php إذا تم إرجاع 500، فابحث عن خطأ في PHP (الحل 1) أو نقص في الذاكرة (الحل 3).

بعد إصلاح المشكلة، ما زلت أرى شاشة بيضاء. ماذا أفعل؟

فكّر في التخزين المؤقت: التصفح الخاص، وحذف الإضافات، وتنظيف شبكة توصيل المحتوى (CDN)، وإذا أمكن، تنظيف ذاكرة التخزين المؤقت OPcache (الحل 5). هذا فخ شائع جدًا.

هل يُعدّ تفعيل خاصية WP_DEBUG على موقع إنتاجي أمرًا خطيرًا؟

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

أي ملف أحتاج إلى تعديله: functions.php، wp-config.php، أو .htaccess؟

للتشخيص: wp-config.php (الحل 1). لتصحيح جزء من الكود: functions.php من قالب الطفل، أو الأفضل من ذلك، إضافة مخصصة (الحل 4 / "تجنب"). .htaccess يُستخدم هذا بشكل أساسي لمشاكل إعادة الكتابة/الروابط الدائمة، وليس لغالبية حالات الشاشة السوداء.

يعود الموقع للعمل عند تعطيل أحد الإضافات، لكنني أحتاج إليه. ماذا أفعل؟

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

مقالات ذات صلة

أرسل تعليقًا

لن يتم نشر عنوان بريدك الإلكتروني. الحقول الإلزامية مشار إليها ب *

هذا الموقع يستخدم Akismet للحد من غير المرغوب فيها. تعرف على المزيد حول كيفية معالجة بيانات التعليقات الخاصة بك.