PHP 8.1 больше не поддерживается: как перейти на PHP 8.4

PHP 8.1 больше не поддерживается: 31 декабря 2025 года ветка получила последний выпуск, 8.1.34, и с тех пор не получает даже исправлений безопасности. Если ваш сайт или сервис всё ещё работает на 8.1 (или тем более на 8.0 и 7.4), каждая новая уязвимость в PHP остаётся в нём навсегда. Разбираемся, на какую версию переходить, что сломается по дороге и как провести переход без сюрпризов на продакшене.

Сроки поддержки версий PHP

Каждая ветка PHP два года получает все исправления и ещё два года — только исправления безопасности. На октябрь 2026 года картина такая:

• PHP 8.1 — поддержка закончилась 31 декабря 2025 года.
• PHP 8.2 — только исправления безопасности, до 31 декабря 2026 года. То есть через пару месяцев 8.2 окажется там же, где сейчас 8.1.
• PHP 8.3 — только исправления безопасности, до 31 декабря 2027 года.
• PHP 8.4 — активная поддержка до 31 декабря 2026 года, исправления безопасности до 31 декабря 2028 года.
• PHP 8.5 — активная поддержка до 31 декабря 2027 года, исправления безопасности до 31 декабря 2029 года.

Чем опасна неподдерживаемая версия: пример PHP2Shell

В октябре 2026 года в PHP нашли две критические уязвимости, PHP2Shell (CVE-2026-109618 и CVE-2026-109619): выполнение кода на сервере без авторизации. Команда PHP выпустила исправленные 8.5.12, 8.4.27, 8.3.36 и 8.2.35, а для 8.1 и старше официальных выпусков не было — только минимальные исправления в исходниках, которые нужно собирать самостоятельно или ждать от поставщика дистрибутива. Подробности — в нашей новости о PHP2Shell.

Так выглядит жизнь на устаревшей ветке: при каждой серьёзной уязвимости вы зависите от того, выпустит ли кто-то бэкпорт, и если выпустит — когда. Некоторые дистрибутивы Linux и коммерческие поставщики продлевают поддержку старых версий, но это временная мера и отдельная зависимость.

На какую версию переходить: 8.4 или 8.5

Переходить на 8.2 сейчас смысла нет: её поддержка закончится 31 декабря 2026 года, и через два месяца переход придётся повторять. Реальный выбор — между 8.4 и 8.5.

• PHP 8.4 — разумный выбор по умолчанию для существующих проектов. Её поддерживают все основные платформы: Magento 2.4.8, Laravel 11, 12 и 13, Symfony 7.4 LTS и 8.1, актуальный WordPress. Исправления безопасности — до конца 2028 года.
• PHP 8.5 — если проект на Magento 2.4.9 (эта версия требует PHP 8.5) или если вы запускаете новый проект и хотите максимальный запас по сроку поддержки — до конца 2029 года. Перед выбором проверьте, что все расширения и библиотеки, от которых зависит проект, уже работают на 8.5.

Совместимость платформ на октябрь 2026 года:

• Magento / Adobe Commerce: 2.4.9 — PHP 8.5; 2.4.8 — PHP 8.4 и 8.3; 2.4.7 — 8.3 и 8.2; 2.4.6 — 8.2 и 8.1. Стандартная поддержка 2.4.6 закончилась 11 августа 2026 года — если магазин на 2.4.6 и PHP 8.1, обновлять придётся и Magento, и PHP.
• Laravel: 12 поддерживает PHP 8.2–8.5 (исправления безопасности до 24 февраля 2027 года), 13 — PHP 8.3–8.5. Laravel 10 и 11 уже не получают исправлений безопасности.
• Symfony: 6.4 LTS требует PHP 8.1+ (исправления безопасности до ноября 2027 года), 7.4 LTS — PHP 8.2+, 8.1 — PHP 8.4+.
• WordPress: рекомендует PHP 8.3 или новее. Формально он работает и на 7.4, но с оговоркой, что такие версии могут подвергать сайт уязвимостям. На практике ограничение обычно задают плагины и тема, а не ядро.

Что сломается при переходе с 8.1 на 8.4

Между 8.1 и 8.4 три ветки, и в каждой есть изменения, которые затрагивают реальный код. Большинство из них сначала проявляются как предупреждения об устаревании, но фреймворки и тесты часто превращают такие предупреждения в ошибки.

• PHP 8.2: динамические свойства. Создание свойства, которое не объявлено в классе, теперь вызывает предупреждение. Это самое массовое изменение в старом коде: исправляется объявлением свойства, атрибутом #[\AllowDynamicProperties] или WeakMap для чужих объектов.
• PHP 8.2: интерполяция "${var}" устарела — нужно "$var" или "{$var}". Устарели utf8_encode() и utf8_decode() (замена — mb_convert_encoding()) и вызовы вида "self::method" через call_user_func().
• PHP 8.3: устарели get_class() и get_parent_class() без аргументов, ++ и -- для пустых и нечисловых строк, assert_options().
• PHP 8.4: неявно nullable-параметры. Запись function foo(Bar $bar = null) устарела — нужно явно ?Bar $bar = null. Встречается почти в каждом старом проекте и во многих зависимостях.
• PHP 8.4: расширения переехали в PECL. IMAP, OCI8, PDO_OCI и PSpell больше не входят в PHP. Если проект читает почту через IMAP или работает с Oracle, расширение нужно ставить отдельно или менять библиотеку.
• PHP 8.4: строже проверка аргументов. exit() стал функцией и бросает TypeError на неверный тип, round() бросает ValueError на неверный режим, атрибуты PDO вроде PDO::ATTR_EMULATE_PREPARES — теперь логические значения. Устарели E_STRICT, trigger_error() с E_USER_ERROR, параметр escape по умолчанию в CSV-функциях, часть настроек сессий.

Отдельная история — зависимости. Старые версии библиотек из Composer могут не поддерживать новый PHP, и тогда переход PHP тянет за собой обновление фреймворка, а оно — свои изменения.

Инструменты

• Rector автоматически переписывает код под новую версию PHP: например, добавляет явные nullable-типы. Конфигурация — RectorConfig::configure()->withPhpSets(): без аргументов Rector берёт версию из composer.json. Изменения Rector нужно просматривать, как обычный код-ревью.
• PHPCompatibility для PHP_CodeSniffer находит несовместимые конструкции без запуска кода: vendor/bin/phpcs -p . --standard=PHPCompatibility --runtime-set testVersion 8.4. Полноту проверки сами авторы не гарантируют, поэтому это дополнение к тестам, а не замена.
• PHPStan со строгим уровнем ловит ошибки типов, которые новые версии PHP превращают из тихих в явные.
• Логи предупреждений об устаревании на тестовом стенде с новым PHP — самый честный источник: показывают, что реально выполняется в вашем коде и в зависимостях.

План перехода

1. Инвентаризация. Какие серверы, версии PHP и режимы работы (PHP-FPM, mod_php, CLI для cron и очередей), какие расширения включены, какие версии фреймворка и пакетов стоят.
2. Выбор целевой версии. 8.4 или 8.5 — по матрице совместимости платформы и ключевых пакетов. Если платформа сама требует обновления (как Magento 2.4.6), планируем оба обновления вместе.
3. Статический анализ и автоматические правки. PHPCompatibility и PHPStan показывают объём работ, Rector закрывает механическую часть.
4. Обновление зависимостей. composer с целевой версией PHP в config.platform показывает, какие пакеты мешают переходу.
5. Тестовый стенд. Копия продакшена на новом PHP: автотесты, ручная проверка ключевых сценариев (оформление заказа, оплата, личный кабинет, импорт и экспорт, cron), логи предупреждений.
6. Выкатка с планом отката. Старая версия PHP остаётся доступной, переключение — в спокойное время, после выкатки — наблюдение за логами и ошибками.

Сколько это займёт

Универсальной цифры нет — объём зависит от нескольких вещей. Насколько код покрыт тестами. Сколько своего кода и насколько он старый: проект, который уже живёт без предупреждений об устаревании на 8.1, переходит заметно легче. Поддерживают ли новый PHP все пакеты и модули — для Magento и WordPress именно сторонние модули и плагины чаще всего становятся главным объёмом работ. И нужно ли заодно обновлять саму платформу. Аудит кода и тестовый прогон на новом PHP за несколько дней дают реальную оценку, а не прикидку.

Мы работаем с PHP, Magento и Laravel больше десяти лет. Проведём аудит совместимости, переведём проект на PHP 8.4 или 8.5 вместе с зависимостями и платформой, проверим на тестовом стенде и выкатим с планом отката.

Источники: поддерживаемые версии PHP, неподдерживаемые ветки PHP, руководства по переходу на PHP 8.2, PHP 8.3 и PHP 8.4, системные требования Adobe Commerce, жизненный цикл Adobe Commerce, политика поддержки Laravel, выпуски Symfony, требования WordPress, Rector, PHPCompatibility.