إضافة ووردبريس قديمة تعطلت بعد تحديث PHP: تجربة 500 واصلاح

رفعت نسخة PHP والموقع اعطى 500 او critical error؟ غالبا في إضافة او قالب يستخدم وظيفة تغيرت او انحذفت. الرجوع لنسخة PHP السابقة ممكن يرجع الموقع مؤقتا، لكنه مش نهاية الحل؛ لازم تحدد الكود غير المتوافق وتحدثه او تستبدله.

بنينا إضافة مختبر لها فرع قديم يستدعي create_function() وفرع حديث يستخدم Closure. على PHP 8.3.30 الدالة القديمة غير موجودة. الطلب القديم رجع HTTP 500 وسجل Call to undefined function. غيرنا الفرع فقط، فصار الرد 200 وخرجت النتيجة المتوقعة.

مشاكل مشابهة تظهر في دعم ووردبريس عن أخطاء توافق PHP وفي نقاش ريديت عن PHP 8.3 وووردبريس. قائمة تغييرات PHP 8 غير المتوافقة الرسمية هي المرجع قبل اي ترقية كبيرة.

نتيجة التجربة

• PHP المستخدم: 8.3.30.
• function_exists('create_function') رجعت false.
• الفرع القديم: HTTP 500 وخطأ undefined function.
• الفرع الحديث: HTTP 200 وCallback من نوع Closure.
• النتيجة بعد الاصلاح: Hello SMSM-28.

الكود القديم فشل فعليا

تعمدنا وضع الاستدعاء داخل endpoint للمختبر حتى ما يمنع تفعيل الإضافة او يسقط كل صفحات الموقع. في مشكلة حقيقية ممكن الاستدعاء يكون في ملف الإضافة الرئيسي، وساعتها تحتاج تعطيلها من الملفات او WP-CLI قبل الدخول.

البديل المتوافق

البديل ما استخدم eval وما احتاج دالة قديمة. لكن نجاح طلب واحد ما يعني ان الإضافة كلها متوافقة. لازم تجرب الاعدادات والحفظ والمهام المجدولة والواجهة والعمليات المهمة.

مصفوفة واضحة بدل التخمين

فيديو توثيق التجربة الفعلية

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

خطة ترقية PHP آمنة

1. خذ نسخة قابلة للاستعادة من الملفات والقاعدة.
2. انسخ الموقع إلى staging بنفس إعدادات الإنتاج.
3. حدث core والإضافات والقالب على النسخة الحالية اولا.
4. راجع متطلبات كل إضافة وحالة صيانتها.
5. غير PHP على staging وشغل smoke tests.
6. افحص error log والتحذيرات حتى لو الواجهة تبدو سليمة.
7. اختبر النماذج والبريد والدفع وCron وREST والمحرر.
8. حدد نافذة رجوع وخطة لاستعادة PHP السابقة اذا فشل الإنتاج.

اقرأ اول خطأ

بعد fatal واحد، ووردبريس ممكن يسجل اخطاء اضافية وهو يحاول recovery mode. ابدأ باول fatal والملف والسطر والاستدعاء. لا تلوم wp-includes تلقائيا اذا stack trace بدأ من إضافة.

اذا ما بتقدر تدخل

غير اسم مجلد الإضافة المتسببة من مدير الملفات او عطلها بـ WP-CLI. لا تحذفها قبل ما تحفظ اسم النسخة والملف والخطأ. اذا الموقع رجع، ثبت ان التعطيل هو السبب ثم قرر تحديث او استبدال.

الرجوع المؤقت

الرجوع لنسخة PHP سابقة مقبول كاحتواء اذا كانت مدعومة امنيا وعندك وقت قصير للاصلاح. لا تبقى على نسخة منتهية الدعم. راجع مزود الاستضافة لان تغيير PHP قد يغير extensions وphp.ini وFPM pool كمان.

علامات عدم التوافق

• Call to undefined function او method.
• TypeError بعد تشديد انواع القيم.
• Deprecated بكميات كبيرة قد تصبح fatal في نسخة لاحقة.
• تحذيرات dynamic properties.
• اخطاء في مكتبة vendor قديمة.
• صفحة تعمل وCron او AJAX يفشل لان المسار مختلف.

لا تعدل الإضافة مباشرة على الإنتاج

تعديل vendor او plugin file قد يضيع مع التحديث ويصعب مراجعة التغيير. الافضل تحديث رسمي او patch موثق في مستودعك واختباره، او استبدال الإضافة. اذا اضطررت لحل طارئ، وثقه واعد تطبيقه بطريقة قابلة للصيانة.

حدود تجربتنا

الإضافة مصممة لتوضح دالة محذوفة واحدة، وما بنقول ان كل مشاكل PHP 8 سببها create_function. الخطأ الحقيقي ممكن يكون types او extension ناقص او مكتبة. الطريقة القابلة للتعميم هي مصفوفة نسخة PHP ونسخة الإضافة واختبار المهمة نفسها.

الخلاصة

الكود القديم رجع 500 على PHP 8.3 لان وظيفته غير موجودة، والـ Closure رجعت 200 على نفس البيئة. ترقية PHP لازم تمر على staging ومصفوفة وظائف وسجل اخطاء، مع رجوع واضح اذا ظهرت إضافة غير متوافقة.