ترقية PHP في ووردبريس: إيه اللي بيكسر الموقع فعلًا؟

دعم PHP 8.2 الأمني بيخلص يوم 31 ديسمبر 2026. موقعك مش هيقفل يوم 1 يناير، بس شركات استضافة كتير هتبدأ تنقل المواقع لإصدارات أحدث، وساعات الموضوع كله بيكون إيميل صغير محدش بيقراه. الأحسن تعرف إيه اللي ممكن يقع قبل ما يحصل.

انتهاء دعم PHP (الاستضافة في نقل المواقع إلى إصدارات أحدث، وقد يحدث ذلك بإشعار…">PHP End of Life) لا يعني توقف الموقع، بل يعني أن الثغرات الجديدة لن تُصلح. ولهذا تفضّل الاستضافات الترقية، وأنت تفضّل أن تكون مستعدًا لها.

1. معظم “أخطاء PHP 8” ليست أخطاء أصلًا

بعد الترقية، ستجد ملف السجل ممتلئًا برسائل مثل هذه:

PHP Deprecated: Creation of dynamic property My_Class::$foo is deprecated

كلمة مُهمَل (Deprecated) تعني أن هذه الطريقة ستتغير في إصدار قادم، والموقع يعمل بشكل طبيعي. اعتبرها مهمة مؤجلة لا حالة طوارئ.

ينطبق الشيء نفسه على تنبيهات PHP 8.1 الخاصة بتمرير null إلى الدوال المدمجة:

PHP Deprecated: strlen(): Passing null to parameter #1 ($string) of type string is deprecated

أصلحها مع الوقت، ولا تقلق منها الآن.

2. ما يُسقط الموقع فعلًا قائمة قصيرة

الخطر الحقيقي هو ووردبريس يظهر غالبًا كرسالة There has been a critical error. من أشهر أسبابه بعد الترقية استدعاء دوال حُذفت من اللغة…">الخطأ القاتل (Fatal Error). وإذا كنت قادمًا من PHP 7.4، فأشهر الأسباب دوال حُذفت تمامًا في PHP 8.0:

// Removed in PHP 8.0: fatal "Call to undefined function"
$callback = create_function( '$a', 'return $a * 2;' );

while ( list( $key, $value ) = each( $array ) ) {
    // ...
}

وجود أي منهما في إضافة مفعّلة واحدة كافٍ لظهور الرسالة الشهيرة:

There has been a critical error on this website.

3. الخطأ الخفي: المُنشئ بالطريقة القديمة

قبل PHP 8.0، كانت الدالة التي تحمل اسم الكلاس نفسه تعمل كمُنشئ (Constructor) تلقائيًا:

class Old_Widget {
    function Old_Widget() {   // a constructor on PHP 7, a normal method on PHP 8
        $this->settings = array();
    }
}

على PHP 8.0 وما بعده تصبح هذه دالة عادية لا تُستدعى أبدًا. لن تظهر أي رسالة خطأ على هذا السطر، لكن الكائن لا يُهيَّأ، وتنكسر وظيفة أخرى لاحقًا في مكان بعيد.

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

4. لا تُخفِ الأخطاء على موقع معطّل

إيقاف عرض الأخطاء للزوار قرار صحيح، لكن إيقاف تسجيلها يعني إخفاء الدليل. فعّل وضع التصحيح (WP_DEBUG) في ملف wp-config.php بهذا الشكل:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // writes to wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // visitors see nothing

بهذا الإعداد تُكتب كل الأخطاء في wp-content/debug.log ولا يرى الزائر شيئًا. لا تنسَ إعادة WP_DEBUG إلى false بعد انتهاء المتابعة.

5. ترتيب الترقية الآمن

1. خذ نسخة احتياطية (Backup) كاملة من الملفات السيرفر.">وقاعدة البيانات.
2. أنشئ بيئة اختبار (Staging)، ومعظم الاستضافات توفرها بضغطة زر.
3. غيّر إصدار PHP على بيئة الاختبار فقط.
4. افحص كل إضافة وقالب على الإصدار الجديد.
5. حدّث أو استبدل ما سينكسر.
6. غيّر الإصدار على الموقع الحي، ثم راقب debug.log لعدة أيام.

الخطوة الرابعة هي الأصعب. التصفح يدويًا يختبر الصفحات التي تزورها فقط، أما الكود الذي يعمل في المهام المجدولة (الشيفرة الخبيثة تلقائيًا بعد كل تنظيف.">Cron) أو الاستيراد أو ردود بوابات الدفع فقد يفشل لاحقًا دون أن تلاحظ.

كيف تفحص الخطوة الرابعة بشكل أذكى

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

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

في Elementor: إصدارات Elementor وElementor Pro وJetEngine الحديثة متوافقة مع PHP 8، لكن المشكلة غالبًا في الإضافات الصغيرة المساعدة (Addons) القديمة أو في كود مخصص داخل functions.php لقالب فرعي كتبه مطوّر سابق. ركّز فحصك على هذه الأجزاء أولًا.

ملاحظة للاستضافات في المنطقة

كثير من الاستضافات المشتركة الرخيصة في مصر والخليج تترك المواقع على إصدارات PHP قديمة لسنوات، ثم تنقلها دفعة واحدة. افتح لوحة cPanel أو ما يماثلها، وابحث عن خيار Select PHP Version أو MultiPHP Manager، وتأكد من الإصدار الحالي بنفسك بدل انتظار الإيميل.

الأسئلة الشائعة

س: هل سيتوقف موقعي إذا بقي على PHP 8.2 بعد ديسمبر 2026؟
ج: لا، سيستمر في العمل. لكنه لن يحصل على إصلاحات أمنية جديدة من PHP، وقد تنقله الاستضافة لإصدار أحدث في أي وقت.

س: ما الفرق بين Deprecated وFatal Error؟
ج: الأول تنبيه بأن شيئًا سيتغير مستقبلًا والموقع يعمل معه. الثاني يوقف التنفيذ فورًا ويُظهر رسالة critical error.

س: ظهرت لي رسالة There has been a critical error بعد الترقية، ماذا أفعل؟
ج: ارجع لإصدار PHP السابق من لوحة الاستضافة فورًا، ثم فعّل WP_DEBUG_LOG واقرأ debug.log لمعرفة الإضافة المسببة، وأصلحها على بيئة الاختبار.

س: هل يكفي أن أتصفح الموقع بعد الترقية للتأكد أنه سليم؟
ج: لا. التصفح لا يختبر المهام المجدولة وعمليات الاستيراد وردود بوابات الدفع. استخدم فحصًا للكود وراقب السجل لعدة أيام.

الخلاصة

متخافش من سيل رسايل Deprecated، اللي يستاهل قلقك هو الدوال المحذوفة والمُنشئات القديمة. خد نسخة احتياطية، جرّب على Staging، افحص الكود، وراقب debug.log، وساعتها ترقية PHP هتعدي من غير ما العميل يكلمك الساعة 2 بالليل.

مرجع المقال (بالإنجليزية): What actually breaks in WordPress when you upgrade PHP (and how to check before your host does it)
المقال ده مش ترجمة حرفية: متكيّف للقارئ العربي ومضاف عليه سياق ووردبريس وElementor وJetEngine.