ما تعنيه نهاية دورة حياة PHP 8.2 عملياً
كل إصدار من PHP يتبع دورة حياة مكوّنة من مرحلتين: سنتان من الدعم الفاعل (تصحيح الأخطاء والثغرات الأمنية)، ثم سنتان من الدعم الأمني فقط — أي أربع سنوات إجمالية لكل إصدار. صدر PHP 8.2 في نوفمبر 2022، وانتهى دعمه الفاعل في 31 ديسمبر 2024. منذ 1 يناير 2025، لا تُنشر سوى التصحيحات الأمنية الحرجة. في 31 ديسمبر 2026، ينتهي حتى هذا الغطاء. الثغرات المكتشفة بعد ذلك التاريخ في محرك PHP 8.2 لن تتلقى أي ترقيع رسمي. ستستمر خوادمك في تشغيل الكود، لكن بدون أي شبكة أمان. الثغرات المنشورة بعد نهاية الدعم ستبقى قابلة للاستغلال إلى أجل غير مسمى على المنشآت غير المُرحَّلة.
المخاطر الفعلية بعد 31 ديسمبر 2026
- ثغرات يوم الصفر بلا ترقيع رسمي — أي ثغرة تُكتشف في PHP 8.2 بعد نهاية الدعم ستبقى قابلة للاستغلال إلى أجل غير مسمى؛ المهاجمون يتابعون هذه المواعيد وينتظرون.
- تعارض متزايد مع الأطر والإضافات — يشترط Laravel 13 (الربع الأول من 2026) PHP 8.3 كحد أدنى ويُسقط رسمياً دعم PHP 8.2؛ المشاريع غير المُرحَّلة لن تستطيع تحديث الإطار.
- ضغط حزم Composer — يتوقف مشرفو الحزم تدريجياً عن الإعلان عن توافق PHP 8.2 في composer.json مما يُسبب تعارضات عند تحديث التبعيات.
- سحب الدعم من مزودي الاستضافة — بعض لوحات التحكم ومزودي الاستضافة المُدارة يُزيلون PHP 8.2 من بيئاتهم مما يُجبر على ترحيل طارئ غير مخطط.
- مخاطر عمليات تدقيق الامتثال — تُصنّف معايير ISO 27001 وPCI-DSS وSOC 2 استخدام بيئات تشغيل منتهية الدعم كمخاطرة غير مقبولة؛ إصدار غير مُصان قد يُعيق الحصول على شهادة.
- تراجع دعم WordPress — توصي WordPress بـ PHP 8.3 كحد أدنى مُوصى به في 2026؛ الإضافات المتميزة تربط دعمها تدريجياً بـ PHP 8.3 أو أحدث.
- تباعد تدريجي في السلوك — تُصحح PHP 8.3 و8.4 سلوكيات داخلية وتُحسّن رسائل الخطأ؛ البقاء على 8.2 يعني فقدان هذه التصحيحات وتوسيع الفجوة مع بيئات التطوير.
جرد بيئتك — رسم خريطة مواقع PHP 8.2
التحدي الأول لأي وكالة ليس تقنياً بل جغرافياً. قبل أي ترحيل، يجب أن تعرف بالضبط كم موقعاً يعمل على PHP 8.2 وتحت أي إعداد خادم. جرد ناقص يُفضي إلى مواقع منسية تبقى مكشوفة بعد تاريخ نهاية الدعم. على كل VPS نفّذ الأمر php -v لكل virtual host أو استشر ملف phpinfo.php المؤقت واحذفه فوراً بعد الاطلاع عليه. على خوادم cPanel أو Plesk، تُظهر واجهة الإدارة إصدار PHP لكل نطاق. سجّل كل موقع في جدول يحتوي على: النطاق، إصدار PHP الفاعل، نظام إدارة المحتوى أو الإطار، إصداره، تاريخ آخر تحديث للتبعيات، ومستوى الأهمية (تجارة إلكترونية، موقع تعريفي، شبكة داخلية).
PHP 8.2 و8.3 و8.4 — دورة الحياة ونهاية الدعم والميزات الأساسية
مرّر الجدول أفقيًا
| المعيار | PHP 8.2 | PHP 8.3 | PHP 8.4 |
|---|---|---|---|
| تاريخ الإصدار | نوفمبر 2022 | نوفمبر 2023 | 21 نوفمبر 2024 |
| نهاية الدعم الفاعل | 31 ديسمبر 2024 | 31 ديسمبر 2025 | 31 ديسمبر 2026 |
| نهاية الدعم الأمني (EOL) | 31 ديسمبر 2026 | 31 ديسمبر 2027 | 31 ديسمبر 2028 |
| الخصائص للقراءة فقط (readonly) | نعم | نعم | نعم |
| ثوابت الصنف ذات النوع | نعم | نعم | نعم |
| خطّافات الخصائص (property hooks) | لا | لا | نعم (ميزة رئيسية) |
| الرؤية غير المتماثلة | لا | لا | نعم |
| json_validate() | نعم | نعم | نعم |
| توافق Laravel 12 | نعم | نعم | نعم |
| توافق Laravel 13 | لا | نعم | نعم |
| توافق Symfony 7.x | نعم | نعم | نعم |
| توافق Symfony 8.x | لا | لا | نعم (يشترط 8.4) |
اختبار التوافق قبل الترحيل
الترحيل دون اختبار مسبق هو السبب الرئيسي لحوادث الإنتاج. أداتان متكاملتان تغطيان جُلّ التحليل الساكن. PHPCompatibility هي مجموعة قواعد لـ PHP_CodeSniffer: تُحلّل الكود المصدري وترصد استدعاءات الدوال المحذوفة والمعاملات المُهملة والتغييرات في السلوك. ثبّتها عبر Composer بالأمر composer require --dev phpcompatibility/php-compatibility وشغّلها مع الهدف --runtime-version=8.3. أما PHPStan فيُجري تحليلاً ساكناً للأنواع: بإعداده على المستوى 5 أو أعلى، يكتشف الخصائص الديناميكية (مُهملة منذ PHP 8.2، وتُسبّب خطأ فادحاً في 8.4) وتعارضات الأنواع وتوقيعات الدوال الخاطئة. يُوصى بتشغيل PHPStan أولاً على قاعدة الكود الحالية لتحديد الخط الأساسي، ثم تغيير إصدار PHP المستهدف إلى 8.3 أو 8.4 في ملف phpstan.neon لتحديد الثغرات.
قائمة التحقق للترحيل إلى PHP 8.3 أو 8.4
رسم خريطة البيئة وتحديد ترتيب الترحيل
أدرج جميع المواقع العاملة على PHP 8.2 مع نظام إدارة المحتوى أو الإطار المستخدم ومستوى الأهمية. أعطِ الأولوية لمواقع التجارة الإلكترونية والتطبيقات الحساسة، واترك مواقع العرض التعريفي للأخير.
تشغيل التحليل الساكن باستخدام PHPCompatibility وPHPStan
شغّل
phpcs --standard=PHPCompatibility --runtime-version=8.3 على مجلد الكود المصدري. صحّح استدعاءات الدوال المحذوفة والخصائص الديناميكية غير المُعلنة قبل الانتقال إلى الخطوة التالية.تحديث تبعيات Composer في بيئة معزولة
في بيئة staging مع تفعيل PHP 8.3 أو 8.4، شغّل
composer update وحلّ تعارضات الإصدارات. تحقق من أن كل حزمة حرجة تُعلن التوافق مع إصدار PHP المستهدف في ملف composer.json الخاص بها.التحقق باستخدام مجموعة الاختبارات الموجودة
شغّل PHPUnit أو Pest أو الاختبارات الشاملة على إصدار PHP المستهدف. إذا لم تتوفر اختبارات آلية، وثّق المسارات الحرجة المختبرة يدوياً (المصادقة، سلة المشتريات، النماذج، webhooks).
تحديث نظام إدارة المحتوى أو الإطار عند الحاجة
WordPress: تحقق من توافق كل إضافة مع PHP 8.3. Laravel: إذا كان المشروع لا يزال على Laravel 11، ادرس الترقية إلى Laravel 12 في نفس وقت ترحيل PHP. Symfony: Symfony 7.4 LTS متوافق مع PHP 8.2 إلى 8.4 دون تغيير الإطار.
تبديل إصدار PHP في الإنتاج
على VPS مع PHP-FPM، عدّل إعداد virtual host في nginx لتوجيهه إلى socket php8.3-fpm.sock أو php8.4-fpm.sock. أعد تحميل nginx وPHP-FPM. على استضافة مُدارة، غيّر الإصدار عبر لوحة التحكم أو واجهة سطر الأوامر.
مراقبة سجلات الأخطاء لمدة 48 ساعة
فعّل تسجيل PHP (
log_errors = On، error_log = /var/log/php/error.log) وراقب التنبيهات والتحذيرات والأخطاء الفادحة لمدة يومي عمل على الأقل بعد التبديل.تحديث الجرد وإشعار العميل
حدّث جدول رسم الخريطة بإصدار PHP الجديد وتاريخ الترحيل. أرسل ملاحظة ختامية للعميل تؤكد الترقية — هذه التتبعية مفيدة أثناء عمليات تدقيق الامتثال.
على VPS، يُتيح PHP-FPM تشغيل إصدارات متعددة بالتوازي دون تعارض: كل virtual host في nginx يشير إلى socket FPM منفصل (php8.2-fpm.sock، php8.3-fpm.sock، php8.4-fpm.sock). هذه البنية تتيح ترحيل موقع بموقع، مع إبقاء المشاريع غير المختبرة على PHP 8.2 بينما تعمل المشاريع المُتحقق منها على 8.3 أو 8.4. إعداد nginx النموذجي: fastcgi_pass unix:/run/php/php8.3-fpm.sock;. ابدأ بالمواقع الأقل حساسية لصقل عملية الترحيل.
الأطر وأنظمة إدارة المحتوى — تواريخ إسقاط PHP 8.2
معرفة جداول أطر التطوير ضرورية لاستشراف قيود الترحيل. Laravel 12، الصادر في 24 فبراير 2025، يدعم PHP 8.2 إلى 8.5 ويتلقى تصحيحات أمنية حتى 24 فبراير 2027. لكن Laravel 13 (الصادر في الربع الأول من 2026) يشترط PHP 8.3 كحد أدنى ويُسقط PHP 8.2 رسمياً. Symfony 7.x (جميع الإصدارات من 7.0 إلى 7.4) يشترط PHP 8.2 كحد أدنى؛ إصدار LTS Symfony 7.4 الصادر في نوفمبر 2025 مدعوم حتى نوفمبر 2029 وهو متوافق مع PHP 8.3 و8.4. أما Symfony 8.x فيشترط PHP 8.4 كحد أدنى. توصي WordPress بـ PHP 8.3 كحد أدنى مُوصى به في 2026. يجب أن تظهر هذه المراحل في خطة الترحيل.
أتمتة مراقبة الإصدارات في بيئة وكالتك
الجرد اليدوي يتقادم بسرعة: العملاء يُضيفون إضافات، يغيّرون مزودي النشر، أو يُنشئون تطبيقات جديدة دون إشعار. أتمتة مراقبة الإصدارات تُبقيك مُطّلعاً دون جهد يومي. عدة مقاربات متكاملة: سكريبت cron بسيط يستجوب php -v عبر SSH على كل خادم ويكتب النتيجة في ملف تقرير مركزي — أداة مثل Ansible أو Fabric تُتيح توازي هذا الجمع على عشرات المضيفين. أدوات مراقبة الخادم تكشف إصدار PHP في مقاييسها وتُطلق تنبيهات عند ظهور إصدار غير مرخص. الهدف أن يُطلق اكتشاف موقع لا يزال على PHP 8.2 بعد 31 ديسمبر 2026 تنبيهاً تلقائياً.
استكشاف الأخطاء — 4 أخطاء شائعة عند الترحيل
تتبع عمليات ترحيل PHP 8.2 → 8.3/8.4 أنماط فشل متكررة. أولاً، الخصائص الديناميكية: منذ PHP 8.2، إضافة خاصية غير مُعلنة لصنف أمر مُهمَل؛ في PHP 8.4 هي خطأ فادح. العَرَض هو تحذير Creation of dynamic property. الإصلاح: إعلان جميع الخصائص في الصنف أو إضافة السمة #[\AllowDynamicProperties]. ثانياً، امتدادات PECL المفقودة: PHP 8.3 و8.4 لا يُجمّعان نفس الامتدادات افتراضياً حسب التوزيعة؛ امتدادات مثل imagick وredis وswoole يجب إعادة تثبيتها صراحةً. تحقق بـ php8.3 -m | grep redis. ثالثاً، تعارضات إصدارات Composer: حزمة تُعلن "php": "^8.2" قد تُثير تعارضاً مع حزمة أخرى تُعلن "php": "^8.3" إذا لم يُعاد توليد composer.lock — شغّل دائماً composer update من الصفر في بيئة staging. رابعاً، توجيهات ini المُهملة: بعض التوجيهات مثل mbstring.func_overload حُذفت؛ ملف php.ini غير مُنظَّف قد يُولّد تحذيرات عند بدء PHP-FPM.
التخطيط المبكر لإدارة بيئة عملائك بسلاسة
لوكالة تدير عشرات المواقع، ترحيل PHP مشروع متعدد المواقع يستوجب قيادته قبل أشهر. ضع خطة بحسب الأولوية التنازلية: مواقع التجارة الإلكترونية والتطبيقات الحرجة أولاً، مواقع العرض أخيراً. أبلغ عملاءك بمخاطر البقاء على PHP 8.2 بعد 31 ديسمبر 2026 — مذكرة خدمة مؤرخة تشرح الآثار الأمنية وامتثالية عادةً ما تكفي لفتح الباب أمام الموافقة والتخصيص الميزانياتي اللازمين. أدرج ترقية إصدار PHP في عقود الصيانة السنوية: سطر مخصص يتجنب إعادة التفاوض لكل ترحيل.
VPS ServOrbit مع PHP-FPM قابل للإعداد
على VPS ServOrbit، تتعايش إصدارات متعددة من PHP-FPM على نفس الجهاز ويشير كل virtual host إلى الإصدار الذي يختاره. الترقية تتم بتعديل سطر واحد في إعداد nginx وإعادة تحميل PHP-FPM — دون إعادة تشغيل الخادم أو انقطاع المواقع الأخرى. للوكالات، VPS مخصص لكل عميل أو VPS مشترك مع عزل PHP-FPM لكل pool يوفر المرونة اللازمة لترحيل موقع بموقع وفق جدولك الخاص.
