شاشة الموت البيضاء في ووردبريس: دليل للتعافي

يحتوي WordPress ، مثل MacOS وحتى Windows الآن ، على "White Screen of Death" أو "WSOD" سيئ السمعة باختصار. يظهر WSOD عندما يحدث خطأ ما. أنت تواجه شاشة بيضاء فارغة أو فارغة في الغالب لأسباب غير معروفة. ماذا الآن؟

ما هي شاشة الموت البيضاء في WordPress (WSOD)؟

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

لماذا ا؟ ما الخطأ الذي حدث؟

منذ إصدار WordPress 5.2 في مايو 2019 ، كان لدى WordPress وضع استرداد لحمايتك من WSOD. بدون وضع الاسترداد ، ستؤدي مشكلات التوافق إلى توليد الكثير من WSODs ومستخدمي WordPress المحبطين. إذا كان الخادم الخاص بك يستخدم إصدارًا من PHP أو MySQL غير مدعوم بواسطة مكون إضافي أو سمة أو امتداد تقوم بتثبيته ، فبدلاً من كسر موقعك ، ستحصل على وضع الاسترداد. اليوم ، ربما يكون خطأ PHP Out-of-Memory (OOM) هو السيناريو الأكثر شيوعًا المتبقي الذي سيتجاوز حماية WSOD ، مما يترك لك شاشة فارغة تمامًا.

لقد تحققت مع المساهم الأساسي في WordPress Marius Jensen لمعرفة ما الذي قد يتسبب في WSOD حقيقي في الوقت الحاضر. ماريوس هو مؤلف المكون الإضافي Site Health (الآن Health Check and Troubleshooting) الذي دخل مفهومه وميزاته في النهاية في جوهر WordPress. (هكذا حصلنا على وضع الاسترداد ووسائل الحماية الأخرى.) أكد ماريوس أن الطريقة الوحيدة لتعطل WordPress بشاشة فارغة تمامًا هي مقاطعة تدفق تنفيذ PHP حتى لا يعمل معالج الأخطاء الفادحة كما ينبغي. سيؤدي قطع الاتصال بين PHP وخادم HTTP إلى تحقيق ذلك. لن تحصل على أي ملاحظات على الشاشة لاستكشاف الأخطاء وإصلاحها. قد يكون هذا محبطًا ، ولكن إذا كنت تعمل ببساطة داخل WordPress ، وتقوم بتثبيت المكونات الإضافية وتكوينها ، فمن غير المرجح أن يحدث هذا.

هل تعني شاشة الموت البيضاء أن WordPress قد تم اختراقه؟

لا ، WSOD لا يعني أن الأشرار قد فهموك. ومع ذلك ، في حالات نادرة ، يمكن أن يكون أحد الآثار الجانبية لخرق أمني. إذا كنت تعتقد أن المتسللين قد اخترقوا موقعك ، فانتقل إلى دليل Kathy Zant ، How to Clean a Hacked WordPress Site.

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

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

مشاهدة المعاينة

شاشة الموت البيضاء في ووردبريس: هل فعلت ذلك؟

نعم. ربما تكون شاشة الموت البيضاء نتيجة لشيء ما أنت فعلت لموقع WordPress الخاص بك.

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

إذا تسببت إحدى المكونات الإضافية أو السمات أو قصاصات كود PHP المعطلة في حدوث خطأ فادح ، فقد تحصل على WSOD. قد تحتوي على خطأ في بناء الجملة أو خطأ أو رمز غير متوافق مع إصدار PHP الذي تستخدمه. إذا قمت أنت أو مضيفك بترقية إصدار PHP الخاص بك - فهذا أمر جيد! - ستبدأ المكونات الإضافية غير المتوافقة في إلقاء الأخطاء وقد تؤدي إلى تعطيل موقعك باستخدام WSOD. إذا كنت تستخدم WordPress 5.2 أو أعلى كما ينبغي ، فستعمل مشكلات عدم التوافق على تنشيط وضع الاسترداد ، وهو مفيد أكثر بكثير من WSOD الحقيقي.

عادةً ما يكون السبب هو كل ما تم تغييره للتو باستخدام مكون إضافي أو سمة أو رمز مخصص.

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

عندما يكون WordPress ميتًا في الغالب

جميع WSODs ليست متساوية ، وبعضها ليس حتى WSODs حقيقي.

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

إذا كانت تجربتك في WSOD تناسب أيًا من هذه الأوصاف ، فهذه أخبار جيدة! موقعك فقط ميت في الغالب . لن يكون من الصعب إحياؤها.

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

وضع استرداد WordPress وشاشة الموت البيضاء

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

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

ستعرض الإصدارات القديمة من WordPress رسائل ذات صياغة متشابهة مثل ، "يواجه الموقع صعوبات فنية".

إذا كنت تستعرض عنوان URL /wp-admin ، فسيكون هناك أيضًا إشعار يخبرك بالتحقق من حساب البريد الإلكتروني للمسؤول للحصول على مزيد من المعلومات:

في حالات أخرى ، قد ترى شاشة بيضاء بها نص غامق يصف "خطأ خادم داخلي" مع نوع من الشرح والإرشادات لإصلاح موقعك.

مرحبًا بك في الاسترداد

هذا هو وضع الاسترداد. يحاول WordPress مساعدتك على استعادة قدميها.

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

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

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

نصيحة للمحترفين: إذا لم تحصل على البريد الإلكتروني لوضع الاسترداد ، فقد تتمكن من تسجيل الدخول إلى WordPress في Recovery Mode على أي حال عن طريق إضافة العنوان التالي إلى عنوان URL لموقعك الأساسي عندما تقوم بتسجيل الدخول كمسؤول: /wp-login.php?action=entered_recovery_mode .

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

ليست كل شاشة الموت البيضاء هي نفسها في WordPress

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

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

هذه ليست مواقف WSOD حقيقية ، لكنها مزعجة بنفس القدر. عادة ، تسبب إحدى الحالات التالية:

1. أنت عالق في وضع الصيانة

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

في بعض الأحيان لا يتم توضيح ذلك في دقيقة واحدة ، ولكن استضافة WordPress ذات الجودة المدارة ستلاحظ ذلك وتصلحه من خلال عملية آلية. إذا انتظرت بضع دقائق دون أي تغيير ، فيمكنك الخروج من وضع الصيانة عن طريق حذف ملف .maintenance . في مجلد جذر الويب / التطبيق حيث تم تثبيت WordPress. (لرؤيتها ، قد تحتاج إلى تمكين عرض الملفات "غير المرئية" برأسها نقطة في اسم الملف.)

عند عدم وجود ملف .maintenance موجود ، سيتم تحميل موقعك بالشكل المتوقع.

2. لقد وصلت إلى تحميل ملف أو حد حجم المنشور

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

الحل: قم بزيادة حد محتوى المنشور الخاص بك في wp-config.php :

 ini_set ('pcre.recursion_limit' ، 20000000) ؛
ini_set ('pcre.backtrack_limit' ، 10000000) ؛

الحل: قم بزيادة حد تحميل الملف وحجم النشر في php.ini :

 upload_max_filesize = 256 ميجا
post_max_size = 256 ميجا

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

 max_execution_time = 300
max_input_time = 300
max_input_vars = 1000
session.gc_maxlifetime = 1000

أو .htaccess أو httpd.conf أو virtualhost :

 php_value upload_max_filesize 256 ميجا
php_value post_max_size 256 م
php_value max_execution_time 300
php_value max_input_time 300
php_value max_input_vars 1000
php_value session.gc_maxlifetime 1000

أو في مقتطف رمز مخصص لـ WordPress أو ملف theme functions.php :

 ini_set ('upload_max_filesize'، '256M') ؛
ini_set ('post_max_size'، '256M') ؛
ini_set ('max_execution_time'، '300') ؛
ini_set ('max_input_time'، '300') ؛
ini_set ('max_input_vars'، '1000') ؛
ini_set ('session.gc_maxlifetime'، '1000') ؛

قيم الذاكرة والوقت في هذه المعلمات هي مجرد توصيات. للتأكد من أنها تعمل والتحقق من قيمها الحالية ، استخدم أداة Site Health في واجهة مسؤول WordPress.

إلى جانب وضع الاسترداد ، قدم WordPress 5.2 أداة صحة الموقع. إنها مفيدة جدًا لتشخيص المشكلات والحصول على معلومات فنية حول إعدادات الموقع وبيئة الخادم. ابحث عنه في قائمة المسؤول الخاصة بك ضمن أدوات> صحة الموقع. يمكنك أيضًا الاستفادة من الميزات الموسعة في المكون الإضافي Health Check and Troubleshooting الخاص بـ WordPress.

3. نفاد ذاكرة PHP

PHP هي لغة البرمجة النصية من جانب الخادم التي يعتمد عليها ووردبريس. يظهر WSOD إذا لم تكن هناك ذاكرة كافية لـ PHP لتشغيل WordPress والمكونات الإضافية النشطة. قد ترى هذا مشار إليه في رسالة خطأ أو سجل.

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

ملف wp-config.php

عادةً ما تؤدي إضافة الإعداد التالي إلى wp-config.php في مجلد WordPress الخاص بك إلى تعيين حد ذاكرة الواجهة الأمامية لـ WordPress إلى 256 ميجابايت في هذا المثال:

 تعريف ('WP_MEMORY_LIMIT'، '256M') ؛

يجب أن يكون حجم 128 إلى 256 ميغا بايت أكثر من كافٍ. قد تتمكن أيضًا من تحديد الحد الأقصى أو الذاكرة الخلفية المخصصة لـ PHP (256 ميجا بايت في المثال التالي أيضًا) عن طريق إضافة السطر التالي إلى wp-config.php أيضًا:

 تعريف ('WP_MAX_MEMORY_LIMIT'، '256M')؛

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

php.ini

هناك طريقة أخرى لتحديد الحد الأقصى لذاكرة PHP وهي الإعداد في ملف php.ini الموجود في مجلد WordPress الخاص بك:

 memory_limit = 256 م

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

htaccess

هناك طريقة ثالثة لتعريف حد ذاكرة PHP وهي من خلال ملف .htaccess في مجلد WordPress الخاص بك إذا كنت تستخدم Apache أو Litespeed كخادم HTTP. مثل الأمثلة أعلاه ، يجب أن يحتوي .htaccess على سطر غير مُعلق مثل هذا لتعيين حد أقصى لـ PHP يبلغ 256 ميجابايت:

 php_value memory_limit 256 م

يمكن أن تتسبب الأخطاء في بناء جملة إعدادات التطبيق والخادم في wp-config.php و php.ini و. .htaccess في حدوث WSOD. قد تحتاج إلى تصحيحها يدويًا أو استبدالها بقيمها الافتراضية الأصلية إذا كانت تخترق موقعك. إذا كنت تستخدم خادم ويب Apache أو Litespeed ، فيمكن تغيير ملف .htaccess الذي يحكم كيفية عملها بواسطة العديد من مكونات WordPress الإضافية. يمكن أن تؤدي الأخطاء التي يتم إدخالها في أي من هذه الملفات إلى ظهور WSOD وإيقاف موقعك.

4. خادم HTTP الخاص بك معطل

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

خوادم HTTP شائعة الاستخدام لمواقع WordPress هي Apache و Litespeed و NGINX. تبدو شاشات الخطأ الخاصة بهم مختلفة قليلاً وقد تختلف في الطرق التي تعرضها المتصفحات ، لكنهم جميعًا يبلغون عن نفس رموز خطأ HTTP.

يشير خطأ HTTP 500 ، المعروف أيضًا باسم خطأ خادم داخلي ، إلى وجود مشكلة غير متوقعة في خادم HTTP تمنعه ​​من تلبية طلبات HTTP. تشير رموز خطأ خادم 5xx الأخرى ، خاصة 502 (بوابة سيئة) و ​​503 (خدمة غير متوفرة) و 504 (مهلة البوابة) ، إلى أن الخادم لديك محمّل بشكل زائد أو يتعذر الوصول إليه. الخطأ الداخلي 500 هو فحص شامل للأعطال الموجودة على الخادم والتي تمنعه ​​من إرجاع الصفحة / المستند المطلوب.

قد يوفر متصفحك عرضًا فريدًا خاصًا به على شاشات خطأ HTTP ، وقد يعرض رموز خطأ خاصة خاصة به. يسرد Google Chrome (والمتصفحات الأخرى المستندة إلى Chromium) ويشرح جميع رموز الأخطاء الخاصة به داخليًا إذا كنت تتصفح للوصول إلى chrome://network-errors/ في شريط العنوان أثناء استخدام Chrome.

مشاكل من جانب الخادم

يشتمل برنامج خادم HTTP المستخدم بشكل شائع لمواقع WordPress على Apache و Litespeed و NGINX. يستخدمها العديد من مضيفي WordPress مع التخزين المؤقت لزيادة الأداء.

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

يمكن أن تتضمن الأسباب الشائعة لخطأ HTTP 500 الشروط التالية من جانب الخادم:

1. تم تجاوز حد ذاكرة PHP.
2. أخطاء PHP الأخرى عندما لا يتم تعيين PHP لعرض الأخطاء.
3. إذن غير كافٍ للوصول إلى ملفات ومجلدات الخادم.
4. أخطاء في بناء الجملة في ملف التكوين htaccess.

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

لا ينبغي أن تحدث الأذونات غير الصحيحة في استضافة WordPress الحديثة والمدارة ، ولكنها شائعة في الاستضافة المشتركة التقليدية. يجب تعيين الملفات على 664 أو 644 ، ويجب تعيين المجلدات على 775 أو 755 ، ويجب تعيين wp-config.php على 660 أو 600 أو 644. تعرف على المزيد حول تغيير أذونات الملفات في WordPress.org.

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

مشاكل جانب العميل

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

5. إعدادات المتصفح غير صحيحة.
6. مخبأ فاسد.
7. تالف ملفات JavaScript التي يتم تشغيلها في متصفحك.
8. مشكلات الاتصال بالإنترنت.

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

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

من الممكن أيضًا أن يكون سبب خطأ HTTP 500 هو مشكلة في قاعدة البيانات ، أو مشكلة في مكون إضافي أو سمة في موقع WordPress ، أو مشكلة في WordPress نفسه.

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

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

عندما يكون WordPress ميتًا حقًا

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

قائمة مراجعة رئيسية لاستكشاف الأخطاء وإصلاحها وإصلاح شاشة الموت البيضاء في WordPress

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

من المنطقي تحديد أولويات الحلول التي تبدو أكثر صلة بموقفك الخاص.

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

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

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

امسح ذاكرة التخزين المؤقت وملفات تعريف الارتباط للمتصفح

يمكن أن تظهر لك الصفحات المخبأة لموقعك في متصفحك وعلى خادمك شيئًا مختلفًا عما يحدث بالفعل. دعنا نتأكد من أنك ترى ما يعرضه WordPress للزوار الجدد لموقعك.

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

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

2. ابحث عن أخطاء PHP

يمكن أن يؤدي رمز PHP في نواة WordPress أو السمات أو المكونات الإضافية إلى حدوث خطأ فادح يجعل WordPress يتخلى عن الشبح مع شاشة بيضاء للموت.

للحصول على مزيد من المعلومات حول أخطاء PHP الفادحة وما الذي يسببها ، يمكنك تشغيل الإبلاغ عن أخطاء PHP وإرسالها إلى الشاشة أو ملف السجل أو كليهما. من المحتمل أن تشير الأخطاء الفادحة إلى مصدر WSOD.

كتطبيق ويب قائم على PHP ، فإن WordPress لديه نظام إعداد التقارير التشخيصية الخاص به لتصحيح الأخطاء الذي يساعدك على الاستفادة من وظائف تسجيل الأخطاء في PHP. لتشغيله والتحكم فيه ، تأكد من وجود سطر في wp-config.php يقول:

 تعريف ('WP_DEBUG' ، صحيح) ؛

قد تحتاج إلى إضافته أو تغيير القيمة من خطأ إلى صحيح. هذا يخبر WordPress بتشغيل تصحيح أخطاء PHP.

يمكنك أيضًا أن تأخذ اختصارًا عن طريق تثبيت وتفعيل المكون الإضافي WP Debugging. سيتم تشغيل تصحيح أخطاء PHP لـ WordPress دون الحاجة إلى تعديل wp-config.php بنفسك مباشرةً.

ستعمل معلمات wp-config.php الإضافية الموضحة أدناه على طباعة إخراج التصحيح على الشاشة بتنسيق HTML وملف باسم "error_log" افتراضيًا:

 تعريف ('WP_DEBUG_DISPLAY' ، صحيح) ؛
تعريف ('WP_DEBUG_LOG' ، صحيح) ؛

قد يكون من المفيد أيضًا إجبار WordPress على استخدام الإصدارات غير المحسّنة من تبعيات CSS و JavaScript الخاصة به في حالة حدوث مشكلة:

 تعريف ('SCRIPT_DEBUG' ، صحيح) ؛

يعد المكون الإضافي Debug Bar أداة إضافية ومكملة مفيدة. سيُظهر لك تصحيح أخطاء البيانات في واجهة لطيفة.

لكي يحدث هذا ، في php.ini ، يجب أن يكون هناك سطر يعطي ثابت error_reporting قيمة أخرى غير NONE ، مثل error_reporting = E_ALL . لا ينبغي أن يكون هناك فاصلة منقوطة عنوان هذا السطر ؛ يجعله تعليقًا وليس إعدادًا نشطًا. لاحظ أنك ستحصل على كل خطأ وتحذير وإشعار PHP إذا كنت تستخدم E_ALL . استخدم قيمة مختلفة مثل E_ERROR لتسجيل أخطاء وقت التشغيل الفادحة التي تتسبب في تعطل WordPress.

3. تحقق من وجود تعارضات في السمات والمكونات الإضافية

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

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

غالبًا ما تكون شاشة الموت البيضاء ناتجة عن تعارضات بين سمات WordPress و / أو المكونات الإضافية. لتحديد مصدر / مصادر التعارض ، يمكنك محاولة إلغاء تنشيط جميع المكونات الإضافية والتبديل إلى حزم السمات الافتراضية الحالية غير المعدلة باستخدام نواة WordPress ، مثل Twenty-Three.

ابدأ بالموضوع - إنه أبسط اختبار. إذا كان تبديل المظهر النشط الخاص بك إلى سمة افتراضية معروفة وغير معدلة يعيد الاتصال بالإنترنت مرة أخرى ، فأنت تعلم أن مشكلتك تكمن في المظهر الذي كنت تستخدمه.

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

استكشاف أخطاء المكونات الإضافية

يمكنك إلغاء تنشيط المكونات الإضافية دون الوصول إلى مسؤول WordPress عبر سطر الأوامر / SSH أو SFTP ببساطة عن طريق نقل مجلدات المكونات الإضافية من المجلد /wp-content/plugins/ مؤقتًا. عملي هو إنشاء مجلد فرعي للمكونات الإضافية يسمى "A" بحيث يظهر أولاً في الدليل المصنف أبجديًا /plugins . ثم أنقل جميع مجلدات المكونات الإضافية الأخرى إلى "أ".

بمجرد القيام بذلك ، أعد تحميل موقعك. سيتصرف WordPress كما لو أن جميع المكونات الإضافية قد اختفت. لا تزال مثبتة ولكن تم إلغاء تنشيطها. إذا اختفت White Screen of Death ، فيمكنك محاولة إعادة تنشيط المكونات الإضافية الخاصة بك والموضوع واحدًا تلو الآخر ، وتحديث صفحتك الرئيسية في كل مرة لمعرفة أيها يتسبب في تعطل موقعك.

Meks Quick Plugin Disabler هي أداة مفيدة تعمل على تعطيل جميع المكونات الإضافية النشطة بسرعة ثم إعادة تمكينها من داخل مسؤول WordPress بأمر منك.

4. إصلاح الملفات الأساسية الفاسدة

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

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

كيفية منع WSOD - نصيحة لمالكي موقع WordPress وبناة

كان WordPress يعمل بشكل جيد - ثم فجأة حصلت على White Screen of Death!

ربما يكون هذا بسبب قيامك بتغيير شيء مهم لعمل WordPress.

إذا كنت تستخدم حساب استضافة WordPress مُدارًا قويًا مع Liquid Web أو Nexcess والذي تم تكوينه بشكل صحيح مع موارد كافية للأشياء التي تقوم بها باستخدامه ، فيمكن تجنب 99 ٪ من الطرق التي يمكنك من خلالها كسر WordPress باستخدام WSOD.

المشكلة هي أن أصحاب المواقع لا يتجنبون هذه الممارسات!

ما الذي عليك عدم فعله

1. ترميز كاوبوي. إضافة أو تحرير رمز وظيفي على موقع مباشر عبر SFTP ، أو سطر الأوامر ، أو محررات التعليمات البرمجية وإدخالات البرامج النصية داخل مسؤول WordPress. خطأ واحد صغير سيؤدي إلى انهيار الموقع. يمكن أن يؤدي تغيير ملفات التكوين مثل .htaccess و wp-config.php الموقع. اعمل على اختبار محلي أو موقع مرحلي مباشر (ولكن ليس عامًا) بدلاً من ذلك.
2. تثبيت السمات والإضافات والملحقات المشكوك فيها. يعد تثبيت برامج منخفضة الجودة أو حتى لاغية على موقع مباشر دعوة للمشاكل. يمكن أن يؤدي إضافة الكثير من الأشياء دفعة واحدة إلى صعوبة تحديد ما هو التغيير المفاجئ في النهاية. على غرار ترميز رعاة البقر ، فإن تثبيت منتجات كود جديدة في موقع مباشر أمر محفوف بالمخاطر. اختبر جيدًا على موقع محلي أو موقع مرحلي خاص أولاً.
3. التخزين المؤقت المعقد. هناك عدة أنواع من التخزين المؤقت من جانب الخادم قد يعرضها مضيفك والتي قد لا تعمل بشكل جيد مع جميع مكونات التخزين المؤقت وتحسين الأداء. عند تنفيذ طرق أو إعدادات تخزين مؤقت جديدة ، اختبر بعناية في البيئات المحلية والتشغيلية قبل تنفيذ التغييرات على موقع مباشر.
4. تحديث كل شيء مرة واحدة. يمكنك تحديث العديد من السمات والإضافات دفعة واحدة. عادةً ما يعمل هذا ، ولكن إذا انتهت مهلة الخادم الخاص بك ، فقد تتعثر في وضع الصيانة. أيضًا ، يمكن أن تؤدي التعليمات البرمجية المحدثة حديثًا إلى حدوث أخطاء جديدة أو تعارضات أو مشكلات توافق. إذا حدث هذا وتعطل موقعك ، فسيكون من الصعب تحديد مصدر المشكلة. يمكن أن يكون أي عدد من العناصر إذا قمت بتحديث العديد من السمات والمكونات الإضافية والإضافات مرة واحدة. يمكن اختبار الكود المحدّث محليًا وعلى مواقع التدريج المباشر قبل طرحه على موقعك العام الرئيسي.

نصائح لحياة بدون WSOD

يمكن أن يحدث WSOD لأي موقع WordPress ، ولكن لا ينبغي أن يكون سببًا للقلق. يمكن أن يساعدك اتباع النصائح الواردة في هذا الدليل في تحديد المشكلة وحلها بسرعة قبل أن يلاحظها زوار موقعك.

تؤكد مشاكل موقع WordPress على أهمية الصيانة والعناية المناسبة. أفضل من الرد على WSODs ، يمكنك تعلم العمل على WordPress بطريقة لن تعرض زوارك أبدًا لرسائل الخطأ والشاشات الفارغة.

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

أفضل مكون إضافي لأمن WordPress لتأمين وحماية WordPress

يعمل WordPress حاليًا على تشغيل أكثر من 40 ٪ من جميع مواقع الويب ، لذلك أصبح هدفًا سهلاً للمتسللين ذوي النوايا الخبيثة. يزيل المكون الإضافي iThemes Security Pro التخمين من أمان WordPress لتسهيل حماية موقع WordPress الخاص بك وحمايته. يشبه الأمر وجود خبير أمان بدوام كامل بين الموظفين الذين يراقبون ويحمون موقع WordPress الخاص بك باستمرار.

احصل على iThemes Security Pro

دان كناوس

دان كناوس هو اختصاصي المحتوى الفني في StellarWP. لقد كان كاتبًا ومدرسًا ومستقلًا يعمل في مصدر مفتوح منذ أواخر التسعينيات ومع WordPress منذ عام 2004.