كيفية إخفاء الأخطاء والتحذيرات في ووردبريس أثناء الطوارئ
أحيانًا تبدأ أخطاء أو تحذيرات PHP بالظهور على موقع ووردبريس الحي فتشوه التصميم أو تربك الزوار. يمكنك إخفاء تلك الرسائل المعروضة مؤقتًا حتى يبدو الموقع العام طبيعيًا من جديد. هذه خطوة طارئة فقط. فهي لا تصلح الخلل ولا تعني أن المشكلة قد اختفت.
مهم: إخفاء التحذيرات أو الأخطاء على الشاشة إجراء مؤقت فقط. منع العرض لا يحل السبب الأساسي. استخدمه فقط كتخفيف قصير الأمد على موقع الإنتاج، ثم افحص السجلات بأمان، وحدد الإضافة أو القالب أو شيفرة PHP المسؤولة، واعمل من نسخة احتياطية أو نسخة تجريبية، وأصلح ذلك الكود أو حدّثه، ثم تحقق من الموقع. لا تعامل الأخطاء المخفية وكأنه من الآمن تجاهلها. إيقاف
WP_DEBUGلا يكتب الأخطاء أيضًا في ملف سجل.
خطوة مؤقتة: إخفاء رسائل الخطأ عن الزوار
يتضمن ووردبريس أصلًا سطر WP_DEBUG في wp-config.php. عدّل ذلك السطر الموجود. لا تلصق define( 'WP_DEBUG', ... ) ثانيًا؛ فتعريف الثابت نفسه مرتين قد يطلق تنبيه PHP. ضع هذه الإعدادات قبل التعليق /* That's all, stop editing! */ وليس بعده.
1. اعثر على wp-config.php
اتصل عبر عميل FTP أو مدير ملفات الاستضافة وافتح wp-config.php في الدليل الجذر لتثبيت ووردبريس.
2. عدّل سطر WP_DEBUG الموجود
ابحث عن السطر الذي يبدو أصلًا مثل define( 'WP_DEBUG', true ); أو define( 'WP_DEBUG', false );. غيّره حتى يتوقف التصحيح:
define( 'WP_DEBUG', false );
استخدم القيمة المنطقية false بدون علامات اقتباس. القيمة 'false' بين علامتي اقتباس سلسلة نصية، وسيعاملها PHP على أنها صحيحة.
3. أخفِ أخطاء PHP المتبقية على الشاشة عند الحاجة
تستمر بعض الاستضافات في طباعة أخطاء PHP حتى مع إيقاف وضع التصحيح في ووردبريس. إذا حدث ذلك، أضف السطر التالي قرب إعداد WP_DEBUG فقط إن لم يكن موجودًا بالفعل:
@ini_set( 'display_errors', 0 );
بعد تعديل حذر، ينبغي أن يبدو ذلك القسم كما يلي، لا كنسختين من WP_DEBUG فوق بعضهما:
define( 'WP_DEBUG', false ); @ini_set( 'display_errors', 0 );
ماذا يفعل هذا:
define( 'WP_DEBUG', false );— يوقف وضع التصحيح في ووردبريس. ينبغي ألا يرى الزوار مخرجات تصحيح ووردبريس بعد ذلك. هذا لا يسجّل الأخطاء عوضًا عنك.@ini_set( 'display_errors', 0 );— يخبر PHP ألا يطبع الأخطاء في HTML الصفحة. إنه إعداد عرض وليس إصلاحًا.
تجنب اعتماد error_reporting(0); أسلوبًا أساسيًا. فهو يكتم تقارير PHP بشدة حتى يصعب معرفة ما الذي تعطّل.
ما يجب فعله بعد ذلك: تشخيص الخطأ الحقيقي وإصلاحه
بمجرد أن يعود الموقع العام مقروءًا، ابحث عن السبب. سير عمل جيد:
- أنشئ نسخة احتياطية قبل تغيير الإضافات أو القوالب أو الشيفرة.
- أعد إنتاج المشكلة على نسخة تجريبية أو موقع محلي كلما أمكن، حتى لا يرى الزوار مخرجات التصحيح.
- على تلك النسخة التجريبية، فعّل التسجيل دون إظهار الأخطاء على الشاشة. ضع هذا قبل
/* That's all, stop editing! */، وحدّث أسطر التصحيح الموجودة بدلًا من تكرارها:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
كيف تعمل هذه الأسطر معًا:
WP_DEBUG— يجب أن يكونtrueحتى تسري ثابتتَا التصحيح الأخريان.WP_DEBUG_LOG— يكتب الرسائل إلىwp-content/debug.log(أو إلى مسار آخر تحدده). ولا يفعل شيئًا إذا كانت قيمةWP_DEBUGهي false.WP_DEBUG_DISPLAY— المضبوط علىfalse، مع ضبطdisplay_errorsعلى0، يُبقي تلك الرسائل خارج الصفحة حتى تقرأها في السجل.
افتح debug.log عبر FTP أو مدير ملفات الاستضافة، لا بتركه قابلًا للتنزيل في المتصفح. يمكن لملف سجل داخل wp-content أن يكشف مسارات الخادم وأسماء الإضافات إذا استطاع أحد جلبه عبر HTTP. بعد الانتهاء، أوقف التصحيح مجددًا واحذف ملف السجل أو قيّد الوصول إليه.
استخدم السجل لتحديد الإضافة أو القالب أو ملف PHP الذي أطلق التحذير أو الخطأ. حدّث ذلك الكود أو أصلحه، ثم أعد تحميل الصفحات المتأثرة للتأكد من اختفاء الرسالة.
يوثّق ووردبريس إعداد التصحيح هذا في دليل المطوّرين.
لماذا لا ينبغي التوقف عند إخفاء الرسالة
يمكن للأخطاء المخفية أن تعطّل الميزات أو تبطئ الموقع أو تبقي مشكلة أمنية قائمة. تنظيف الشاشة يحمي الزوار فقط أثناء عملك. الهدف الحقيقي هو موقع مستقر حُلّت مشكلته الأساسية.
الخلاصة
في حالة الطوارئ يمكنك إخفاء مخرجات أخطاء ووردبريس وPHP بتعديل سطر WP_DEBUG الموجود إلى false، وإيقاف display_errors عند الحاجة — دائمًا قبل تعليق “stop editing”، ودون تعريف الثابت نفسه مرتين. ثم شخص السبب على نسخة احتياطية أو موقع تجريبي مع تسجيل التصحيح، وأصلح الإضافة أو القالب أو شيفرة PHP المسؤولة، وتحقق. إخفاء التحذير مؤقت؛ أما إصلاح الخطأ فهو ما يبقى.
