متطلبات PHP في Laravel وSymfony أواخر 2026: فترات الدعم وترتيب الترقية الآمن

يضبط إطار العمل ساعتين لتطبيقك: إصدارات PHP التي يعمل عليها، والمدة التي يتلقى فيها إصلاحات الأخطاء والأمان. ولـ PHP نفسه ساعة ثالثة. وعندما تنتهي أي واحدة منها يصبح تطبيقك قائمًا على شيفرة غير مدعومة. يعرض هذا الدليل موقف Laravel وSymfony الحالي كما ورد في صفحات الإصدارات الرسمية لكل مشروع في 31 أكتوبر 2026، مع ترتيب للترقية يجنّبك الوقوع في طريق مسدود.

جدول PHP نفسه

بحسب php.net: يتلقى PHP 8.2 إصلاحات أمنية حتى 31 ديسمبر 2026، وPHP 8.3 حتى 31 ديسمبر 2027، وPHP 8.4 حتى 31 ديسمبر 2028، وPHP 8.5 حتى 31 ديسمبر 2029، أما PHP 8.1 فانتهى دعمه في 31 ديسمبر 2025. وعلى مستوى حزم التوزيعات تأتي ديبيان 13 ‏(trixie) مع PHP 8.4، وديبيان 12 ‏(bookworm) مع PHP 8.2، وأوبونتو 24.04 مع PHP 8.3، وأوبونتو 22.04 مع PHP 8.1.

Laravel

يصدر Laravel إصدارًا رئيسيًا كل عام تقريبًا في الربع الأول. وتمنح سياسة الدعم كل إصدار رئيسي 18 شهرًا من إصلاحات الأخطاء وعامين من إصلاحات الأمان:

ماذا يعني ذلك عمليًا؟

• Laravel 11 وما قبله خارج الدعم، فلم تعد تصلها إصلاحات أمنية من فريق Laravel.
• Laravel 12 في مرحلة الإصلاحات الأمنية فقط حتى 24 فبراير 2027. وإذا كان يعمل على PHP 8.2 فسيحل موعدان متقاربان: نهاية PHP 8.2 آخر ديسمبر 2026، ونهاية Laravel 12 في فبراير 2027.
• Laravel 13 يُسقط PHP 8.2. ويطلب دليل الترقية نقل laravel/framework إلى ^13.0 مع حزم مرتبطة مثل laravel/tinker ‏^3.0 وphpunit/phpunit ‏^12.0.

Symfony

يتبع Symfony نموذجًا زمنيًا: إصدارات فرعية في مايو ونوفمبر، وإصدار رئيسي كل عامين، وإصدار دعم طويل الأمد (LTS) في نهاية كل خط رئيسي. والفروع المدعومة اليوم هي:

وصل Symfony 8.0 إلى نهايته في يوليو 2026، ومن المقرر صدور Symfony 8.2 في نوفمبر 2026 وهو يتطلب أيضًا PHP 8.4 أو أحدث. وينتج عن ذلك أمران: أولًا، خط Symfony 8 كله يحتاج إلى PHP 8.4، فلا يعمل على PHP 8.2 الذي تأتي به ديبيان 12 ولا على PHP 8.3 الذي تأتي به أوبونتو 24.04. ثانيًا، الإصدارات الفرعية غير طويلة الأمد مثل 8.1 تُدعم نحو ثمانية أشهر فقط، فالفرق التي لا تستطيع الترقية مرتين في السنة يناسبها خط الدعم الطويل، وهو اليوم 7.4.

اقرأ القيود الفعلية في مشروعك

جداول الأطر نقطة البداية، أما القرار فلملف composer.lock. هذه أوامر Composer تجيب عن الأسئلة العملية:

php artisan --version           # Laravel
php bin/console --version       # Symfony
composer show laravel/framework # or symfony/http-kernel
composer prohibits php 8.4      # which packages block PHP 8.4, and why
composer check-platform-reqs    # does this server's PHP and extensions satisfy the lock file?

يسرد الأمر composer prohibits php 8.4 كل حزمة مثبتة تستبعد قيودها هذا الإصدار، وهو أسرع طريقة لتقدير حجم ترقية PHP. أما check-platform-reqs فيتجاهل عمدًا إعداد config.platform ويفحص ملف PHP التنفيذي والإضافات الحقيقية، فشغّله على الخادم بإصدار PHP نفسه الذي يستخدمه الموقع.

وإذا كان المطورون يعملون محليًا على إصدار PHP أحدث من الإنتاج، فثبّت المنصة المستهدفة في composer.json حتى لا يختار composer update حزمًا لا يستطيع الإنتاج تشغيلها:

{
    "config": {
        "platform": {
            "php": "8.3.0"
        }
    }
}

وتنبّه وثائق Composer إلى أن هذا الإعداد يجعله يثق بالإصدار المذكور بدل الحقيقي، ولهذا توصي بتشغيل check-platform-reqs ضمن خطوات النشر.

ترتيب آمن للترقية

1. انقل PHP أولًا إلى إصدار يدعمه إطارك الحالي والإطار المستهدف معًا. يعمل Laravel 12 على 8.2 حتى 8.5، ويعمل Laravel 13 على 8.3 حتى 8.5، فانقل تطبيق Laravel 12 من PHP 8.2 إلى 8.3 أو 8.4 وانشره، ثم رقِّ الإطار بعد ذلك. وفي Symfony يحتاج الانتقال من 6.4 إلى 7.4 إلى PHP 8.2 على الأقل، وأي خطوة إلى 8.x تحتاج إلى PHP 8.4.
2. رقِّ الإطار في فرع مستقل. حدّث القيود التي يذكرها دليل الترقية، وشغّل composer update ثم الاختبارات والفحوص الساكنة.
3. انشر على بيئة تجريبية بإصدار PHP والإضافات نفسها الموجودة في الإنتاج، وشغّل هناك composer check-platform-reqs.
4. أعد تشغيل العمليات طويلة الأمد في كل نشر. تحتفظ عمليات طوابير Laravel بالشيفرة القديمة في الذاكرة حتى يطلب منها php artisan queue:restart الخروج بهدوء، وتحتاج عمليات Symfony Messenger إلى php bin/console messenger:stop-workers بعد وضع الشيفرة الجديدة على القرص وتسخين الذاكرة المؤقتة، ثم يعيد مدير العمليات تشغيلها.
5. اجعل سطر الأوامر والويب على إصدار PHP نفسه. مهام cron والعمليات الخلفية وComposer تستخدم ملف سطر الأوامر، فاستدعِ الملف ذا الرقم (php8.4) صراحة على الخوادم التي تضم أكثر من إصدار.

أخطاء شائعة

• ترقية الإطار وPHP في خطوة واحدة، فيصعب تحديد سبب أي عطل.
• اعتماد ملف composer.lock حُلّت قيوده على إصدار PHP محلي أحدث من الإنتاج.
• نسيان العمليات الخلفية التي تواصل تشغيل الشيفرة القديمة وإصدار PHP القديم حتى يُعاد تشغيلها.
• التعامل مع نهاية دعم الإطار كأمر اختياري، فبعدها تتوقف إصلاحات الأمان لهذا الخط حتى لو ظل التطبيق يعمل.

ما الذي ينبغي فعله

1. اجرد لكل تطبيق إصدار الإطار وإصدار PHP الذي يعمل عليه في سطر الأوامر وفي الويب.
2. انقل تطبيقات Laravel 11 وما قبله، وأي تطبيق على PHP 8.1 أو أقدم، إلى إصدارات مدعومة على سبيل الأولوية.
3. خطط لنقل تطبيقات Laravel 12 إلى PHP 8.3 أو 8.4 قبل 31 ديسمبر 2026، ثم إلى Laravel 13 قبل 24 فبراير 2027.
4. في Symfony فضّل خط 7.4 طويل الأمد ما لم تستطع مواكبة كل إصدار فرعي نصف سنوي، وتذكّر أن Symfony 8 يتطلب PHP 8.4.
5. أضف composer check-platform-reqs وإعادة تشغيل العمليات الخلفية إلى كل عملية نشر.

المصادر

• laravel.com/docs/13.x/releases
• laravel.com/docs/12.x/releases
• laravel.com/docs/13.x/upgrade
• laravel.com/docs/13.x/queues
• symfony.com/releases
• symfony.com/releases.json
• symfony.com/releases/6.4.json
• symfony.com/releases/7.4.json
• symfony.com/releases/8.0.json
• symfony.com/releases/8.1.json
• symfony.com/releases/8.2.json
• symfony.com/doc/current/messenger.html
• getcomposer.org/doc/03-cli.md#check-platform-reqs
• getcomposer.org/doc/03-cli.md#prohibits-why-not
• getcomposer.org/doc/06-config.md#platform
• php.net/supported-versions.php
• php.net/eol.php