تطوير الويب٣ يوليو ٢٠٢٦11 دقائق قراءة

حل مشكلة الخطأ الفادح في ووردبريس للمطورين

حل الخطأ الفادح في ووردبريس بأمان عبر وضع الاسترداد وسجلات PHP وعزل الإضافة أو القالب واستخدام WP-CLI وخطة رجوع منظمة.

كتبهBakry Abdalsalam

حُدث١ أغسطس ٢٠٢٦

يبني بكري عبدالسلام مواقع الويب والتطبيقات والتكاملات ومنتجات ووردبريس، ويوثق مركز بكري التقني القرارات التقنية وراء هذا العمل.

الخلاصة

احفظ الأدلة، اقرأ Fatal Error الأصلية، اعزل أصغر Component سببت الفشل، ثم أصلح أو ارجع الإصدار بصورة منظمة. التعطيل العشوائي قد يخفي السبب ويكسر وظائف أخرى.

رسالة «There has been a critical error on this website» تخفي خطأ PHP الفادح عن الزائر، لكنها لا تشرح سببه. ستجد الخطأ الأصلي عادة في رسالة وضع الاسترداد أو سجل PHP أو خادم الويب أو ملف تصحيح أخطاء مؤقت.

قبل تغيير Plugins أو Theme أو PHP Version، سجل الحالة الحالية حتى لا تضيع الدليل.

ثبّت الحالة واحفظ معلومات الحادث

سجل:

أول وقت معروف لظهور الخطأ.
الروابط المتأثرة وهل تعمل /wp-admin/.
آخر Deploy أو Update أو تعديل إعداد.
إصدارات PHP وWordPress والـTheme والـPlugins.
هل المشكلة عامة أم داخل إجراء محدد.

إذا كان Release جديد هو السبب الواضح ولديك Rollback مجربة، أعد الإصدار السليم مع الاحتفاظ بالسجلات. خذ نسخة Database وFiles قبل إصلاح يدوي عندما تكون البيانات ما زالت تتغير.

استخدم وضع الاسترداد

يستطيع WordPress Recovery Mode اكتشاف بعض Fatal Errors أثناء Page Load وإرسال رابط خاص إلى بريد المدير. عند الدخول يوقف Component المسببة داخل Session التشخيص لتستعيد الوصول.

تأكد من صحة الرسالة والنطاق قبل فتح الرابط. إذا لم يصل البريد، راجع Admin Email وMail Delivery ثم انتقل إلى SSH أو لوحة الاستضافة.

الإشارة إلى Plugin لا تعني دائماً أن العيب داخلها وحدها؛ قد تكشف Memory Exhaustion أو عدم توافق PHP.

اقرأ رسالة الخطأ الفادح الأصلية

ابدأ من سجلات PHP-FPM وNginx:

sudo journalctl -u php8.3-fpm --since "30 minutes ago"
sudo tail -n 100 /var/log/nginx/error.log

تختلف الأسماء والمسارات حسب الاستضافة.

عند الحاجة فعّل File Logging مؤقتاً في wp-config.php قبل سطر إيقاف التحرير:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

أعد الخطأ مرة واحدة ثم اقرأ wp-content/debug.log. بعد التشخيص أوقف Debug واحذف السجل أو احمه؛ قد يحتوي Paths وبيانات أو أسراراً.

ابحث عن أول Fatal Error مرتبطة بالوقت والمسار، وسجل نوع الاستثناء والرسالة والملف والسطر. Warnings التالية قد تكون مجرد نتائج جانبية.

افهم أنماط الأخطاء

Call to undefined function أو undefined method: إصدار غير متوافق أو Dependency ناقصة.
Cannot redeclare: تحميل كود مرتين أو Conflict.
Allowed memory size exhausted: استهلاك غير محدود أو Query أو معالجة صورة ثقيلة أو Limit منخفضة.
Uncaught TypeError: بيانات غير متوقعة أو اختلاف PHP.
Failed opening required: ملف Plugin أو Theme أو Vendor ناقص.
Parse error: تحديث ناقص أو Syntax غير متوافقة.

رفع Memory Limit قد يعيد الخدمة لعمل شرعي، لكنه ليس بديلاً عن معرفة من استهلك الذاكرة.

اعزل الإضافة المشتبه بها

إن كانت لوحة التحكم تعمل، أوقف Plugin التي يشير إليها Stack Trace واختبر. افهم أثرها قبل تعطيل Payment أو Membership أو Security.

عبر WP-CLI:

wp plugin list --status=active
wp plugin deactivate suspected-plugin

إذا تعذر إقلاع WordPress غيّر اسم مجلد Plugin المحددة:

mv wp-content/plugins/suspected-plugin \
   wp-content/plugins/suspected-plugin.disabled

تغيير اسم مجلد plugins كله قد يعيد الوصول، لكنه يزيل معلومة مهمة وقد يكسر وظائف كثيرة. استخدمه فقط كعزل واسع مقصود، ثم اختبر المكونات واحدة واحدة في Staging.

لا تحذف الإصدار المعطل فوراً؛ قد تحتاجه لتحليل السبب أو Rollback.

اختبر القالب وإصدار PHP

إذا أشار Stack Trace إلى Theme أو Child Theme، فعّل Default Theme مثبتة داخل Staging:

wp theme list
wp theme activate twentytwentyfive

تأكد من وجود Theme قبل الأمر. عند اختفاء الخطأ راجع آخر التعديلات وتوافق Parent Theme وHooks ومتطلبات PHP. لا تجعل إصلاحاً دائماً داخل Parent Theme أو Vendor File.

قارن إصدار PHP وExtensions:

php -v
php -m
wp core version

قد تختلف CLI عن PHP-FPM، لذلك تحقق من Web Runtime أيضاً.

افحص اكتمال التحديث والملفات

بعد Deploy جزئي ابحث عن:

مجلد vendor ناقص.
Disk ممتلئ.
Ownership غير صحيحة.
ملفات من إصدارين مختلفين.
تحديث توقف في منتصف النسخ.

تحقق من Core Checksums:

wp core verify-checksums

الاختلاف دليل يحتاج تفسيراً، خاصة مع Localized أو Managed Files. استبدل Core من Release موثوقة مطابقة، لا من Archive مجهولة.

إذا بدأ Nginx يعيد 502 بسبب انهيار PHP-FPM، اتبع دليل 502 في Nginx وPHP-FPM بالتوازي مع تحليل Fatal Error.

تأكد من الإصلاح

بعد Rollback أو Patch مستهدفة:

امسح Cache المتأثرة فقط.
اختبر المسار والإجراء الأصلي.
اختبر Login وwp-admin وForms وCheckout وCron وAPI حسب المكون.
تأكد من عدم ظهور Fatal Errors جديدة.
لا تعِد Components الموقوفة قبل إثبات التوافق.
أوقف Debug المؤقتة.
وثق السبب والإصدار والإصلاح ومنع التكرار.

أعد تجربة التحديث في Staging قريبة من PHP وحجم بيانات الإنتاج.

أخطاء شائعة ومنعها

تجنب تعطيل كل Plugins عشوائياً، تعديل الإنتاج بلا Backup، عرض أخطاء PHP للزوار، رفع الذاكرة بلا حد، حذف الإصدار المسبب، أو تحديث عدة مكونات أثناء الحادث.

استخدم Staged Updates وImmutable Releases وRollback مجربة ومراقبة Logs ونسخاً احتياطية تختبر استعادتها. وبعد الاستقرار راجع تحسين LCP في ووردبريس لتحسين الأداء بالقياس لا بإضافات طوارئ.

أسئلة شائعة

ماذا أفعل إذا لم تصل رسالة Recovery Mode؟

استخدم لوحة الاستضافة أو SSH أو SFTP أو WP-CLI لقراءة السجلات وعزل Component المذكورة. وبعد استقرار الموقع راجع بريد المدير وتسليم الرسائل.

هل أوقف كل الإضافات أولاً؟

فقط كخطوة طوارئ مقصودة. Stack Trace وآخر تغيير غالباً يسمحان باختبار أضيق يحفظ الدليل ولا يعطل وظائف تجارية غير مرتبطة.

مراجع رسمية

لديك سؤال عن هذا الدليل أو فكرة لتعاون تقني؟ تواصل مع بكري عبر المركز التقني.

نهاية الملاحظة.