الشاشة البيضاء في ووردبريس وخطأ 500: اقرأ سجل الأخطاء أولًا، ثم أعد تسمية الإضافات فالقالب فملف htaccess. خطوات مرتبة وجدول للأسطر. اقرأ قبل أن تحذف.
- شركة برمجيات مصرية منذ 2010
- دعم فني على واتساب
الإجابة المختصرة: الشاشة البيضاء في ووردبريس وخطأ 500 عرضان لمشكلة واحدة في الغالب: كود يتوقف عن العمل على السيرفر، وأكثر ما يسببه إضافة أو قالب أو ملف htaccess تالف أو نفاد الذاكرة. لا تبدأ بالحذف ولا بإعادة التثبيت، بل افتح سجل الأخطاء أولًا فهو يخبرك باسم الملف المتسبب، ثم اتبع ترتيب إعادة التسمية الآمن الموضح هنا.
الشاشة البيضاء في ووردبريس وخطأ 500 والرسالة الحرجة: ثلاث صور لمشكلة واحدة
يستخدم الناس ثلاثة أوصاف لما يبدو لهم عطلًا واحدًا، لكن الفرق بينها يفيد في التشخيص.
- الشاشة البيضاء: صفحة فارغة تمامًا بلا رسالة. يحدث ذلك غالبًا حين يتوقف PHP (لغة البرمجة التي يعمل بها ووردبريس) بسبب خطأ فادح، ويكون عرض الأخطاء مغلقًا فلا يظهر شيء.
- خطأ 500 (Internal Server Error): رسالة من السيرفر نفسه تقول إن شيئًا أخطأ دون تفاصيل. تقول وثائق ووردبريس الرسمية إن ملف htaccess التالف هو السبب الأرجح، وقد يكون السبب إضافة أو قالبًا أو حدًّا للذاكرة.
- رسالة «حدث خطأ فادح في هذا الموقع»: هذه رسالة ووردبريس نفسه حين يلتقط الخطأ. وتنصح الوثائق بالنظر في بريد مدير الموقع الإلكتروني بحثًا عن تعليمات، وتذكر من أسبابها الشائعة تعارض الإضافات وعدم توافق القالب وإصدارًا غير متوافق من PHP وبلوغ حد الذاكرة وتلف ملفات ووردبريس.
لاحظ أن الأسباب متقاطعة. لذلك لا يصح أن تبدأ بتخمين السبب الأول. وهناك ملاحظة سريعة تساعدك: إن كانت لوحة التحكم تفتح بينما واجهة الموقع بيضاء، فالمشتبه القالب أو إضافة تعمل في الواجهة فقط. وإن تعطل الاثنان معًا فالمشتبه إضافة أو ملف htaccess أو الذاكرة أو إصدار PHP.
قاعدة «السجل أولًا»: لا تعطّل شيئًا قبل أن تقرأ
أكثر ما نراه عند من يواجه الشاشة البيضاء أنه يبدأ فورًا بتعطيل إضافات وحذف أخرى وتغيير القالب في وقت واحد. فإذا عاد الموقع لا يعرف أي خطوة أعادته، وإن لم يعد فقد صار الوضع أسوأ لأنه غيّر أشياء كثيرة. سجل الأخطاء يختصر هذا كله، لأنه يسجل سطرًا يحدد نوع الخطأ والملف ورقم السطر.
القاعدة إذن بسيطة: اقرأ أولًا، ثم غيّر شيئًا واحدًا، ثم افحص، ثم غيّر الثاني. وتغيير واحد في كل مرة يعني أنك تعرف دائمًا ما الذي أصلح الموقع، وهذه المعرفة هي التي تمنع تكرار العطل بعد أسبوع. وقبل أي تعديل، انسخ احتياطيًا الملف الذي ستغيّره، أو خذ نسخة كاملة من الموقع إن كان لديك الوقت.
أين تجد سجل الأخطاء؟
الطريقة الأولى: سجل الاستضافة
معظم الاستضافات تحتفظ بسجل أخطاء دون أن تفعل شيئًا. في لوحة cPanel ابحث عن قسم Errors، وفي مدير الملفات ابحث عن ملف باسم error_log داخل مجلد الموقع أو داخل مجلد wp-admin. وتختلف الأسماء والأماكن بين المضيفين، فإن لم تجده فاسأل الدعم الفني: «أين سجل أخطاء PHP لهذا الدومين؟». افتح آخر أسطر الملف فقط، فهي المتعلقة بعطلك الآن.
الطريقة الثانية: وضع التصحيح لدقائق ثم إطفاؤه
إذا لم تجد سجلًا، فعّل التسجيل من ملف wp-config.php. تقول وثائق ووردبريس الرسمية إن هذه الأسطر تُضاف قبل السطر الذي يحوي عبارة «stop editing»:
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
السطر الأول يشغّل وضع التصحيح، والثاني يكتب الأخطاء في ملف debug.log داخل مجلد wp-content، والثالث يمنع ظهورها على الشاشة أمام الزوار، وتنص الوثائق على أن يُقرن بالثاني. بعد تحميل الصفحة المعطلة مرة واحدة افتح الملف واقرأ آخر الأسطر.
وهنا التحذير الذي لا نتهاون فيه: تذكر الوثائق نفسها أنه لا يُنصح باستخدام وضع التصحيح وأدواته على المواقع الحية، وأن الأولى استخدام نسخة تجريبية أو نسخة احتياطية حديثة. فإن اضطررت إلى استخدامه على موقع حي، فاجعله دقائق معدودة، وأبقِ العرض على الشاشة مغلقًا كما في السطر الثالث، ثم أطفئه بعد القراءة واحذف ملف debug.log، لأنه قد يحوي مسارات ملفاتك ومعلومات لا تريدها أن تكون متاحة. لا تترك الوضع مفعّلًا بعد أن يعود الموقع إلى العمل.
ماذا يقول السطر الذي وجدته؟
لا تحتاج أن تفهم كل كلمة في السجل. ابحث عن كلمة الخطأ ثم عن مسار الملف، وخاصة الجزء الذي يتبع wp-content. هذه الأسطر الشائعة وما تعنيه:
| ما يظهر في السطر | معناه | الخطوة التالية |
|---|---|---|
| خطأ فادح (Fatal error) ومسار فيه wp-content/plugins/اسم-الإضافة | كود تلك الإضافة توقف أو لا يتوافق مع إصدار PHP | أعد تسمية مجلد تلك الإضافة وحدها، ثم افحص الموقع |
| الخطأ نفسه ومسار فيه wp-content/themes/اسم-القالب | المشكلة في القالب أو في ملف وظائفه | فعّل قالبًا افتراضيًا أو أعد تسمية مجلد القالب |
| استدعاء دالة غير معرّفة (Call to undefined function) | كود يطلب شيئًا غير موجود، وغالبًا بسبب إصدار PHP أو امتداد ناقص أو إضافة ناقصة | راجع إصدار PHP، وأعد رفع الإضافة من مصدرها |
| خطأ في بنية الكود (Parse error) | أحدهم عدّل ملفًا وأخطأ في كتابته | ارجع إلى النسخة السابقة من ذلك الملف |
| نفاد حجم الذاكرة المسموح (Allowed memory size exhausted) | ووردبريس لم يجد ذاكرة تكفي لمهمة ما | ارفع حد الذاكرة، وابحث عن الإضافة الثقيلة |
| أمر غير صالح في htaccess (Invalid command) | ملف htaccess فيه سطر لا يفهمه السيرفر | أعد تسمية الملف وولّد غيره من الروابط الدائمة |
| اسم ملف لا تعرفه أو لم تثبّته أنت | قد يكون ملفًا خبيثًا لا خطأ توافق | توقف، وراجع قسم «متى تتوقف» أدناه |
قد لا يظهر في السجل كل ما تتوقعه، فبعض الأخطاء تُسجَّل في ملف الاستضافة وبعضها في debug.log. فإن لم تجد ما يفسر العطل في الأول فجرّب الثاني.
ترتيب إعادة التسمية الآمن
إعادة تسمية مجلد أو ملف عن طريق مدير الملفات أو FTP أسلم من الحذف، لأن الاسم القديم يرجع في ثانية ولا يضيع شيء. وهذا الترتيب مأخوذ من توصيات ووردبريس الرسمية ومن ممارسة يومية، ونطبق خطوة واحدة في كل مرة ثم نفحص.
الخطوة 1: الإضافات
إن كان السجل يحدد إضافة بعينها فأعد تسمية مجلدها وحده داخل wp-content/plugins، كأن تضيف _old إلى اسمه. وإن لم يحدد، فأعد تسمية مجلد plugins كله، وتقترح الوثائق الاسم plugins_old. افتح الموقع. إذا عاد، فالسبب إضافة. أعد الاسم الأصلي للمجلد، ثم ادخل لوحة التحكم، وستجد الإضافات كلها معطلة. فعّلها واحدة واحدة وافحص الموقع بعد كل واحدة حتى يعود العطل، فتعرف المتسببة.
الخطوة 2: القالب
إن بقي العطل، أعد تسمية مجلد القالب النشط داخل wp-content/themes. يعود ووردبريس إلى قالب افتراضي إن كان مثبّتًا، وهذا ما تقترحه الوثائق. إن عاد الموقع فالمشكلة في القالب، وعليك أن تراجعه أو تستبدله. ولا تحذف قالبك قبل أن تحفظ نسخة منه إن كان فيه تعديلات.
الخطوة 3: ملف htaccess
في حالة خطأ 500 تحديدًا، أعد تسمية الملف .htaccess إلى .htaccess_old. وتقول الوثائق إنه السبب الأرجح لهذا الخطأ. جرّب تحميل الموقع. إذا عمل، فادخل إلى الإعدادات ثم الروابط الدائمة واضغط حفظ ليولّد ووردبريس ملفًا جديدًا سليمًا. ولا تنسَ أن الملف مخفي في بعض البرامج حتى تفعّل عرض الملفات المخفية.
الخطوة 4: حد الذاكرة
إن أشار السجل إلى نفاد الذاكرة، فارفع الحد في wp-config.php. هذا هو المثال الذي تعرضه الوثائق بقيمة 96 ميجابايت، ويصح أن تضع قيمة أخرى تناسب موقعك:
define( ‘WP_MEMORY_LIMIT’, ’96M’ );
وتحذّر الوثائق من أن بعض المضيفين لا يسمحون برفع الحد تلقائيًا، فإن لم يتغير شيء فاطلب من الاستضافة رفعه. وإن كان موقعك يستهلك الذاكرة باستمرار، فالحل الدائم أن تعرف الإضافة الثقيلة، وراجع دليل تسريع ووردبريس لتخفيف الحمل.
الخطوة 5: إعادة رفع ملفات ووردبريس
هذه آخر الخطوات وليست أولاها. تقترح الوثائق إعادة رفع مجلدي wp-admin و wp-includes من نسخة نظيفة حديثة من ووردبريس إذا تلفت الملفات. لا تلمس wp-content ولا wp-config.php في هذه العملية، ففيهما بياناتك. وإن لم تكن واثقًا مما تفعل، فهذه نقطة توقف وسؤال.
مثال افتراضي: عطل بعد تحديث إضافة
هذا مثال متخيَّل لتوضيح الترتيب، وليس حالة عميل. يحدّث مالك متجر إضافة الشحن مساءً، فيجد صباح اليوم التالي صفحة بيضاء في واجهة الموقع بينما تعمل لوحة التحكم. العلامة الأولى مفيدة: لوحة التحكم سليمة، فالمشتبه إضافة تعمل في الواجهة أو القالب.
لا يعطّل المالك شيئًا. يفتح سجل الأخطاء من لوحة الاستضافة فيجد في آخره سطر خطأ فادح ومسارًا يمر بمجلد إضافة الشحن. يعيد تسمية مجلد تلك الإضافة وحدها، ويحمّل الموقع فيعود. بعدها يراجع صفحة الإضافة، فيرى أن الإصدار الجديد يحتاج إصدار PHP أحدث من المثبّت لديه. يعيد الإضافة إلى نسخة سابقة من نسخته الاحتياطية، ويؤجل التحديث حتى يرفع PHP بخطة سليمة. لم يحذف شيئًا، ولم يغيّر أكثر من خطوة واحدة، ويعرف تمامًا ما حدث.
ما لا تفعله أثناء العطل
الذعر يدفع إلى قرارات تحوّل عطلًا يُصلح في دقائق إلى مشكلة تستغرق أيامًا. هذه الأفعال نتجنبها نحن، ونوصيك بتجنبها.
- لا تعد تثبيت ووردبريس قبل أن تعرف السبب، فلن يعالج إضافة أو قالبًا أو ملف htaccess.
- لا تحذف wp-config.php ولا مجلد wp-content، ففيهما إعدادات قاعدة البيانات وبيانات موقعك وصورك.
- لا تغيّر أكثر من شيء في المرة الواحدة، فلن تعرف أيها أصلح الموقع ولا أيها زاد الأمر سوءًا.
- لا تعدّل الملفات مباشرة على الموقع الحي بلا نسخة من الملف الأصلي.
- لا تترك وضع التصحيح مفعّلًا، ولا تنشر محتوى السجل علنًا في مجموعة أو منتدى، فهو يكشف مسارات الملفات.
- لا تنفّذ كودًا نسخته من مجهول لتصليح الشاشة البيضاء دون أن تفهم ما يفعل.
بعد أن يعود الموقع: اعرف لماذا حدث
العودة إلى العمل ليست نهاية الأمر. اسأل نفسك: ما الذي تغيّر قبل العطل مباشرة؟ في أغلب الحالات يكون الجواب تحديثًا لإضافة أو قالب أو ووردبريس، أو تغييرًا لإصدار PHP، أو تعديلًا يدويًا في ملف. إن كان سبب العطل تغيير الإصدار، فاقرأ خطوات تحديث PHP في ووردبريس بأمان لتعرف كيف تعيد المحاولة دون أن يتكرر الأمر. وإن كان الخطأ يظهر مع رسالة «خطأ في إنشاء اتصال بقاعدة البيانات» فمشكلتك مختلفة، ويشرحها مقال خطأ الاتصال بقاعدة البيانات.
ثم اكتب في سطرين ما حدث وما أصلحه، ليكون لك مرجع حين يتكرر. وخذ نسخة احتياطية جديدة بعد استقرار الموقع. والعادة التي تحميك من هذا كله هي نسخة احتياطية تعرف أنها تُستعاد فعلًا قبل كل تحديث، وخطواتها في دليل اختبار استعادة النسخ الاحتياطية.
متى تتوقف وتسأل مختصًا؟
تحدد هذه الحالات الحد الذي ينتهي عنده ما يصلح أن تفعله بنفسك:
- موقعك يدرّ دخلًا وكل ساعة عطل تكلفك طلبات، ولا تستطيع قراءة السجل بثقة.
- السجل يذكر ملفًا لا تعرفه أو لم تثبّته أنت، أو مجلدًا باسم عشوائي داخل wp-content أو داخل مجلد الرفع. قد يكون هذا علامة اختراق لا خطأ توافق، وعلاماته في دليل اكتشاف اختراق ووردبريس والتعافي منه. لا تحاول التنظيف بتخمين ما يجب حذفه.
- العطل يتكرر بعد كل إصلاح، أو يعود بعد ساعات.
- طُبّقت الخطوات الأربع الأولى وبقي الموقع معطلًا.
وتفيد إجراءات الحماية العامة، مثل التحديث المنتظم وكلمات المرور القوية، في تقليل الحالات من هذا النوع، وتجدها في دليل أمان الموقع.
وحين تتواصل مع الدعم الفني لأي جهة، فأعطه ما يوفر وقت الجميع: نص الخطأ كما يظهر، ووقت بدئه، وآخر تغيير أجريته، وآخر الأسطر من السجل.
ما الذي نفعله في برمجلى؟ نقرأ السجل قبل أن نغيّر شيئًا
برمجلى شركة برمجة واستضافة في القاهرة منذ 2010، ولدينا 89 موقعًا لعملاء نشغّل لهم الاستضافة. في عملنا كشركة استضافة نبدأ دائمًا بالسجل ونأخذ نسخة قبل أي تغيير، ونغيّر شيئًا واحدًا في كل مرة حتى نعرف السبب الحقيقي. إن كان عطل موقعك يحتاج إصلاح كود في قالب أو إضافة مخصصة، فهذا من عمل خدمة البرمجة المخصصة وإصلاح الأخطاء لدينا. لا نعد بأن كل موقع يعود في دقائق، فبعض الحالات تكشف مشكلة أعمق في الكود أو اختراقًا يحتاج تنظيفًا أطول. راسلنا على واتساب وأرسل لنا نص الخطأ ووقت بدايته، وسنخبرك بما نراه.
المصادر
- WordPress Developer Resources, Common WordPress Errors
- WordPress Developer Resources, Debugging in WordPress
- WordPress Developer Resources, Editing wp-config.php
أسئلة شائعة
ما سبب الشاشة البيضاء في ووردبريس؟
تقول وثائق ووردبريس الرسمية إن السبب غالبًا إضافة تسبب مشكلة توافق أو القالب، وخصوصًا بعد تفعيل قالب جديد. ويمكن أن يكون السبب كذلك نفاد الذاكرة أو إصدار PHP غير متوافق. سجل الأخطاء يحدد الملف المتسبب بدل التخمين.
كيف أصلح خطأ 500 في ووردبريس؟
ابدأ بقراءة سجل الأخطاء. ثم أعد تسمية ملف htaccess إلى htaccess_old وجرّب الموقع، فتذكر وثائق ووردبريس أنه السبب الأرجح. إن عمل الموقع فاحفظ الروابط الدائمة من الإعدادات ليولّد ملفًا جديدًا. وإن لم يعمل فانتقل إلى الإضافات ثم القالب ثم الذاكرة.
كيف أعطّل الإضافات إذا لم أستطع دخول لوحة التحكم؟
ادخل عبر مدير الملفات في لوحة الاستضافة أو عبر FTP، وافتح مجلد wp-content، وأعد تسمية مجلد plugins إلى plugins_old. بذلك تتعطل الإضافات كلها فورًا، ويمكنك دخول لوحة التحكم، وإعادة الاسم الأصلي ثم تفعيل الإضافات واحدة واحدة.
هل يمكنني ترك WP_DEBUG مفعّلًا؟
لا. تذكر وثائق ووردبريس أنه لا يُنصح باستخدام أدوات التصحيح على المواقع الحية. فعّله لدقائق مع إغلاق عرض الأخطاء على الشاشة، واقرأ الملف، ثم أطفئه واحذف ملف السجل، لأنه قد يكشف مسارات ملفاتك.
هل أعيد تثبيت ووردبريس عند ظهور الشاشة البيضاء؟
لا تبدأ بذلك. المشكلة في الغالب إضافة أو قالب أو ملف htaccess أو الذاكرة، وإعادة التثبيت لا تعالج أيًّا منها وقد تضر ببياناتك. اقرأ السجل أولًا، فإن أشار إلى تلف ملفات ووردبريس نفسها فأعد رفع مجلدي wp-admin و wp-includes فقط.
خدمات مرتبطة
- تصميم مواقع الشركات في مصر
- إنشاء متجر إلكتروني
- برمجة مواقع وأنظمة خاصة
- ايميل رسمي للشركات
- أتمتة واتساب للشركات
- نظام شركات السياحة
