كيفية إصلاح الشاشة البيضاء لخطأ الموت في WordPress (WSoD)

نشرت: 2023-01-10

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

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

  • لماذا أرى شاشة الموت البيضاء في ووردبريس؟
  • الخطوة # 1 - ابدأ بمسح ذاكرة التخزين المؤقت لموقعك
  • الخطوة # 2 - تحقق من سجلات أخطاء PHP
  • الخطوة # 3 - تحديد الأخطاء باستخدام وضع التصحيح
  • الخطوة # 4 - زيادة حد ذاكرة WordPress و PHP
  • الخطوة # 5 - استرجع آخر التغييرات التي أجريتها
  • الخطوة # 6 - تعطيل المكونات الإضافية
  • الخطوة # 7 - استعادة نسخة احتياطية للموقع
  • خيار التصحيح: تحقق من المشكلات المحتملة مع الموضوع الخاص بك

لماذا أرى شاشة الموت البيضاء في ووردبريس؟

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

مثال على خطأ الشاشة البيضاء لخطأ الموت (wsod)

قبل أن ندخل في كيفية تحديد سبب الخطأ على موقعك وإعادة تشغيل كل شيء - إليك تفاصيل الأسباب الأكثر شيوعًا:

  • أخطاء كود PHP (غالبًا ما يحدث تحديث للمكوِّن الإضافي)
  • استنفاد حد ذاكرة PHP

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

لذلك ، دون مزيد من اللغط - دعنا نلقي نظرة على كيفية إصلاح خطأ WSoD على موقع الويب الخاص بك:

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

الخطوة # 1 - ابدأ بمسح ذاكرة التخزين المؤقت لموقعك (بما في ذلك ملحقات التخزين المؤقت)

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

ملاحظة: يتضمن هذا أيضًا أي طبقات إضافية للتخزين المؤقت قد تكون لديك. على سبيل المثال ، التخزين المؤقت للمكونات الإضافية - تأكد من مسحها بالإضافة إلى التخزين المؤقت على مستوى الخادم في مكانه.

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

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

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

cd ~/public

wp cache flush --skip-plugins --skip-themes

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

إذا كان لا يزال لا يعمل ، فتابع القراءة للحصول على حلول محتملة أخرى ...

الخطوة # 2 - تحقق من سجلات أخطاء PHP

ملاحظة: إذا لم تكن مرتاحًا لقراءة ملفات السجل ، فيرجى الانتقال إلى الخطوة رقم 3.

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

تعرف على المزيد حول عرض وفحص ملفات السجل هنا.

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

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

الخطوة # 3 - تحديد الأخطاء باستخدام وضع التصحيح

يمكن أن يساعدك وضع "التصحيح" المدمج في WordPress في تحديد أي أخطاء على الخادم. لتمكين وضع التصحيح في WordPress ، افتح ملف wp-config.php الخاص بك ، وقبل السطر الأخير ، أضف الكود التالي:

// Enable WP_DEBUG mode

define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file

define( 'WP_DEBUG_LOG', true );

ملاحظة: سيؤدي تمكين وضع WP_DEBUG إلى عرض جميع أخطاء وإشعارات وتحذيرات PHP. يمكن أن يعرض هذا أخطاء ورسائل تحذير للأشياء التي لم يتم كسرها أيضًا ولكن لا تتبع قواعد تطوير WordPress (و / أو PHP).

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

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

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

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

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

الخطوة # 4 - زيادة حد ذاكرة WordPress و PHP

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

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

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

لإصلاح ذلك ، يمكنك زيادة حجم الذاكرة المتاحة للمكونات الإضافية المختلفة. سجّل الدخول إلى خادمك باستخدام SFTP ، ثم ابحث عن ملف wp-config.php. في معظم الحالات - بما في ذلك في Servebolt - سيكون في مجلدك العام .

افتح ملف wp-config.php ، وأضف السطر التالي في الأسفل:

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

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

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

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

وضع حد أعلى لذاكرة Php في لوحة تحكم Servebolt

الخطوة # 5 - استرجع آخر التغييرات التي أجريتها

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

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

قد ترغب في التفكير في استخدام Git ، لأنه يجعل من السهل جدًا تتبع التغييرات واستدعاء التكرارات السابقة. سوف يقوم Git بتخزين أي تغييرات تجريها ، مما يسمح لك باسترجاعها عند الحاجة.

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

الخطوة # 6 - تعطيل المكونات الإضافية

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

إذا لم تتمكن من الوصول إلى منطقة لوحة القيادة ، فسيتعين عليك الاتصال بموقعك باستخدام عميل SFTP مثل FileZilla . ابحث عن مجلد wp-content ، وسترى دليلًا باسم "plugins".

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

تعطيل الإضافات في ووردبريس

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

الخطوة # 7 - استعادة نسخة احتياطية للموقع

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

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

يتم تخزين النسخ الاحتياطية لمدة تصل إلى 30 يومًا ، مع تخزين نسخة احتياطية واحدة يوميًا لآخر 14 يومًا ، وبضع نسخ احتياطية أسبوعية قبل ذلك.

خيار التصحيح: تحقق من وجود مشاكل مع الموضوع

وورد المواضيع

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

ماذا لو لم أتمكن من الوصول إلى لوحة تحكم المسؤول؟

إذا كنت تحصل على White Screen of Death عند محاولتك الوصول إلى لوحة تحكم المسؤول ، فمن الواضح أن تغيير السمة لن يكون من الممكن القيام بنفس الطريقة.

بدلاً من ذلك ، يمكنك استخدام SFTP للوصول إلى ملفات الموقع.

بمجرد دخولك إلى الموقع ، ما عليك سوى:

  1. ابحث عن مجلد webroot ، ثم انتقل إلى دليل محتوى wp.
  2. من هناك ، ابحث عن مجلد باسم "السمات". ابحث بالداخل عن اسم المظهر النشط الخاص بك.
  3. بعد ذلك ، قم ببساطة بإضافة اللاحقة "_old" بعد اسم دليل السمة ، واحفظ التغييرات. سيقوم WordPress بتعطيل السمة (وإذا كان لديك سمة افتراضية مثبتة ، فانتقل إلى هذا المظهر افتراضيًا).
  4. حاول الوصول إلى موقع الويب الخاص بك مرة أخرى.

إذا كان لديك وصول إلى SSH ، فيمكنك تغيير السمة إلى سمة أخرى باستخدام WP-CLI .

في هذا المثال ، يتم تغييره إلى موضوع Twenty-Two.

wp theme activate twentytwentytwo --skip-plugins --skip-themes

ملاحظة: يتخطى هذا الأمر تهيئة المكونات الإضافية والسمات عند إجراء هذا التغيير.

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

تقرير ما بعد الإجراء - اتصل بدعم الاستضافة الخاص بك لاتخاذ إجراءات وقائية

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

لا تستخدم Servebolt حتى الآن ، ولكن هل أنت مهتم بالاستضافة المدارة الأسرع تجريبياً؟

جرب WordPress على Servebolt اليوم:

    • قابلية التوسع: في اختبارات عبء عمل المستخدم الحقيقي ، قدم Servebolt متوسط ​​أوقات استجابة 65 مللي ثانية ، وأوقات استجابة أسرع 4.9 مرة من ثاني أفضل.
    • أسرع أوقات تحميل عالمية: وضع متوسط ​​أوقات تحميل الصفحة على مستوى العالم البالغ 1.26 ثانية Servebolt في أعلى قائمة نتائج WebPageTest العالمية .
  • أسرع سرعة للحوسبة: توفر خوادم Servebolt سرعة غير مسبوقة لقاعدة البيانات ، وتعالج 2.44 مرة استعلامات في الثانية أكثر من المتوسط ​​، وتعمل PHP 2.6 مرة أسرع من ثاني أفضل!
  • أمان مثالي ووقت تشغيل: مع وقت تشغيل بنسبة 100٪ على جميع الشاشات ، وتقييم A + على تطبيق SSL الخاص بنا ، يمكنك التأكد من أن موقعك متصل وآمن.

كل ذلك مدعوم من قبل فريق الخبراء لدينا وعلى استعداد لاتخاذ جولة في اختبار Bolt المجاني اليوم .