كلُّ إصدار من PHP أسرع من سابقه ويتلقّى إصلاحاتٍ أمنيّة نحو ثلاث سنوات. والسبب الوحيد لألّا تشغّل إصدارًا مدعومًا هو أن شيئًا تعتمد عليه لا يعمل عليه — وذلك سؤالٌ له جواب لا تخمين.
نافذةُ الدعم هي الحدّ الأدنى
- الدعم النشط: إصلاحُ العلل والثغرات، نحو سنتين.
- والدعم الأمني: الأمن وحده، سنةً أخرى.
- وبعد ذلك: لا شيء، أبدًا. فالثغرة المعروفة تبقى مفتوحة على خادمك إلى الأبد.
تشغيلُ إصدارٍ غير مدعوم ليس خيارًا في الصيانة، بل بابٌ مفتوح. وهو كذلك من أوّل ما يفحصه مسحٌ آليّ.
افحص قبل أن تنتقل
composer why-not php 8.3
vendor/bin/rector process --dry-run
phpcs --standard=PHPCompatibility --runtime-set testVersion 8.3 app/السطر الأول يسمّي الحزم التي تُبقيك متأخّرًا. وهي في الغالب مكتبةٌ واحدة مهجورة، واستبدالها عملٌ أصغر من البقاء متأخّرًا إلى الأبد.
إن كان في الأمر نظامُ إدارة محتوى
راجِع صفحة التوافق للنواة ولكل إضافة. فإضافةٌ لم تُحدَّث منذ ثلاث سنوات هي سببُ تعثّرك، وهي كذلك مشكلةٌ أمنيّة بذاتها.
الانتقال بأمان
- خذ نسخةً احتياطية — انظر انسخ قبل كل تحديث.
- غيّر بيئة التجريب أوّلًا — وجرّب الدفع والرفع والبريد ومهامّ الجدولة.
- انقل بيئة الإنتاج مع إبقاء الإصدار القديم منصَّبًا — حتى يكون الرجوع سطرًا واحدًا.
- راقب سجلّ الأخطاء يومًا — فتنبيهات الإهمال تصل مع الزيارات لا مع الاختبارات.
وإصدارُ مهامّ الجدولة عندك
php -v # the CLI
curl -sSI https://yourdomain.com | grep -i x-powered-byإصدارُ سطر الأوامر وإصدارُ الويب إعدادان منفصلان. فمهمّةٌ ليليّة على إصدارٍ قديم بينما الموقع على إصدارٍ جديد تنتج أعطالًا لا تقع إلّا ليلًا — انظر إبقاء PHP مُرقَّعًا.