ماذا يعني انتهاء دعم إصدار PHP
يتبع كل إصدار من PHP دورة حياة منظّمة: سنتان من الدعم النشط تشملان إصلاحات الأخطاء وتصحيحات الأمان، تليهما سنة واحدة من دعم الأمان فحسب. عند انتهاء هذه الدورة يدخل الإصدار في حالة انتهاء الدعم (EOL). بالنسبة لـ PHP 8.2 هذا التاريخ هو 31 ديسمبر 2026. بمجرد مرور هذا التاريخ لن تتلقى الثغرات المكتشفة في PHP 8.2 أي تصحيح رسمي. ستواصل خوادمك تشغيل الكود، لكنها ستفعل ذلك دون أي شبكة أمان. ستبقى ثغرات CVE المنشورة بعد 31 ديسمبر 2026 قابلة للاستغلال إلى أجل غير مسمى على الأنظمة غير المُرحَّلة.
المخاطر الفعلية بعد 31 ديسمبر 2026
- **ثغرات zero-day دون إصلاح** — الثغرات المكتشفة في PHP 8.2 بعد انتهاء الدعم لن تتلقى تصحيحات رسمية، مما يُعرّض تطبيقاتك للاستغلال فور الإعلان عنها.
- **عدم توافق متصاعد مع الأطر البرمجية** — يتطلب Laravel 12 PHP 8.3 كحد أدنى؛ ويوصي WordPress 6.7 والإضافات المتميزة بـPHP 8.3 وتبدأ في التخلي عن دعم 8.2.
- **إزالة من بيئات الاستضافة** — بعض مزودي الاستضافة يزيلون PHP 8.2 من بيئاتهم المُدارة، مما يفرض ترحيلًا طارئًا غير مخطط له.
- **خطر أثناء عمليات التدقيق** — تُصنّف مرجعيات مثل ISO 27001 وPCI-DSS وSOC 2 استخدام أوقات تشغيل منتهية الدعم بوصفه خطرًا غير مقبول.
- **تعارضات Composer** — تتوقف الحزم تدريجيًا عن الإعلان عن توافقها مع PHP 8.2، مما يُسبّب تعارضات عند تحديث التبعيات.
إعداد الجرد: تحديد جميع المواقع التي تعمل على PHP 8.2
أول تحدٍّ تواجهه الوكالة ليس تقنيًا، بل هو رسم الخريطة. قبل أي عمل ترحيل تحتاج إلى معرفة عدد المواقع التي تعمل على PHP 8.2 وتكوين الخادم المستخدم لكل منها. الجرد غير المكتمل يُفضي إلى مواقع منسية تظل مكشوفة بعد الموعد النهائي. على كل VPS أو خادم مشترك، نفّذ php -v لكل مضيف ظاهري أو استشر ملف phpinfo.php المنشور مؤقتًا، وسجّل جميع الإصدارات النشطة في جدول بيانات مشترك مع السياق.
قائمة التحقق للترحيل إلى PHP 8.3 أو 8.4
اختبار التوافق في بيئة اختبار
قبل إجراء أي تغيير في الإنتاج، انسخ الموقع على نسخة اختبار مع تفعيل PHP 8.3 أو 8.4. حدّد تحذيرات الاستهلاك، والأخطاء الحرجة، وعدم التوافق مع الإضافات.
تحديث التبعيات
نفّذ composer update في بيئة الاختبار وحلّ تعارضات الإصدارات. تأكد من أن كل حزمة تُصرّح صراحةً بتوافقها مع إصدار PHP المستهدف في ملف composer.json الخاص بها.
التحقق باستخدام مجموعة الاختبارات
شغّل PHPUnit أو Pest أو الاختبارات الشاملة الموجودة على إصدار PHP المستهدف. إذا كان المشروع يفتقر إلى الاختبارات، أعطِ الأولوية للمسارات الحيوية بالاختبار اليدوي الموثق.
تبديل الإصدار في الإنتاج
بعد اكتمال التحقق، غيّر إصدار PHP النشط في تكوين المضيف الظاهري (مجمع PHP-FPM أو إعداد مزود الاستضافة)، ثم راقب سجلات الأخطاء لمدة 24 إلى 48 ساعة.
عزل المشاريع الصعبة باستخدام Docker
حين تكون للمشاريع متطلبات متباينة جدًا من حيث الإضافات أو إعدادات ini، يوفر Docker عزلًا كاملًا: يمتلك كل تطبيق وقت تشغيل PHP الخاص به وإضافاته، دون أي تداخل مع الحاويات المجاورة.
على VPS، يتيح PHP-FPM تشغيل إصدارات متعددة بالتوازي: كل مضيف ظاهري في nginx يُشير إلى مجمع FPM منفصل (مثلاً php82-fpm.sock وphp83-fpm.sock). يُمكّنك هذا من ترحيل موقع تلو الآخر دون التأثير على المشاريع الأخرى. ابدأ بالمواقع الأقل حساسية لتطوير عمليتك.
التخطيط المسبق لإدارة محفظة العملاء بسلاسة
بالنسبة لوكالة تدير عشرات المواقع، يُعدّ الترحيل إلى PHP مشروعًا متعدد المواقع يستوجب التنسيق قبل أشهر. ضع جدولًا زمنيًا بحسب الأولوية: المواقع التجارية الحيوية أولًا، والمواقع الإعلانية أخيرًا. أبلغ عملاءك بمخاطر البقاء على PHP 8.2 بعد 31 ديسمبر 2026. بالنسبة للمشاريع التي تستخدم Docker، يختزل الترحيل في تغيير صورة أساسية في ملف Dockerfile.
