PHP 7.4 устарел: что делать и как перейти на PHP 8

Что на самом деле означает «PHP 7.4 устарел»

У каждой ветки PHP есть жизненный цикл из двух этапов. Сначала идёт активная поддержка: разработчики исправляют ошибки и закрывают уязвимости. Затем наступает период только безопасности, когда выходят лишь критические патчи. После этого ветка получает статус EOL (end of life): никаких обновлений нет вообще.

У PHP 7.4, выпущенной в ноябре 2019 года, активная поддержка закончилась в ноябре 2021-го, а исправления безопасности прекратились в ноябре 2022-го. Это значит, что любая уязвимость, обнаруженная в ядре или стандартных расширениях после этой даты, в 7.4 официально не исправляется.

Важный нюанс: устаревшая версия не «ломается» в один день. Сайт продолжает открываться, формы отправляются, заказы приходят. Именно поэтому проблему так часто откладывают, пока не случится взлом или хостер не отключит старую версию.

Чем грозит работа на устаревшей версии

Главный риск — безопасность. Уязвимости в PHP, как правило, публикуются открыто, и автоматические сканеры ботов проверяют сайты на известные дыры массово. Сайт на EOL-версии оказывается в зоне повышенного риска: взлом, внедрение вредоносного кода, рассылка спама с вашего домена, утечка клиентской базы.

Второй риск — совместимость. Современные версии WordPress, Laravel, Symfony, популярные плагины и пакеты Composer поднимают минимальную требуемую версию PHP. Рано или поздно вы не сможете поставить обновление безопасности для самой CMS, потому что оно потребует PHP 8.

Третий риск — последствия для поиска. Если сайт взломан, Яндекс Вебмастер и Google Search Console могут показать предупреждение о вредоносном коде, а в выдаче появится пометка об опасности. Трафик из Яндекса и Google при этом падает быстро, а восстановление занимает недели.

Какую версию PHP выбрать вместо 7.4

Логично сразу целиться в ветку, у которой впереди как можно больше лет поддержки, но не в самую свежую, если вы используете много сторонних плагинов. Они могут не успеть добавить совместимость с последним релизом.

Для большинства коммерческих сайтов золотая середина сегодня — PHP 8.2 или 8.3. Для нового проекта и современного кода на фреймворках подойдёт PHP 8.4. Версии 8.0 и 8.1 разумно рассматривать только как промежуточный шаг при поэтапной миграции, так как их сроки поддержки закончились или заканчиваются.

Актуальный график всегда публикуется на официальном сайте php.net, поэтому перед принятием решения сверьтесь с ним: даты могут уточняться.

Подготовка: сначала аудит, потом переключатель

Самая частая ошибка — зайти в панель хостинга, выбрать в списке PHP 8.3 и надеяться на лучшее. Так можно получить белый экран на всём сайте. Миграция должна начинаться с инвентаризации: какая версия PHP стоит сейчас, какие расширения подключены, какая CMS и какие плагины используются, есть ли самописный код.

Узнать версию можно командой php -v в консоли или через phpinfo(). Для проектов на Composer полезны команды composer check-platform-reqs и composer why-not php 8.3: они покажут, какие пакеты мешают переходу. Для сайтов на CMS проверьте в описании каждого плагина и темы заявленную поддержку PHP 8.x и дату последнего обновления. Заброшенный плагин, который не обновлялся несколько лет, почти всегда становится главной проблемой.

Что чаще всего ломается при переходе на PHP 8

Переход с 7.4 на 8.0 — самый «болезненный», потому что именно в нём изменено больше всего поведения языка. Часть notice превратилась в warning, многие функции стали выбрасывать исключение TypeError при неверных типах аргументов, а сравнение строк с числами стало более логичным и строгим.

Удалены или изменены устаревшие конструкции: функция create_function и each больше не существуют, обращение к символу строки через фигурные скобки удалено, оператор @ больше не скрывает фатальные ошибки. В PHP 8.1 и 8.2 добавились новые предупреждения об устаревании, например о динамических свойствах классов в 8.2. Они не ломают сайт сразу, но засоряют логи и подсказывают, что код нужно привести в порядок.

Ниже — наглядный пример того, как меняется поведение одного и того же кода.

Как действовать грамотно

Не пытайтесь победить все предупреждения одним махом. Сначала устраните фатальные ошибки и TypeError, потому что они ломают работу сайта. Затем разберитесь с Warning, которые влияют на логику. Предупреждения Deprecated можно планово убирать в следующем спринте.

Если код писали давно и не документировали, оцените объём работ заранее: прогон PHPStan на среднем уровне строгости уже даёт ясную картину, сколько мест требует правок.

Если обновиться прямо сейчас невозможно

Бывает, что проект завязан на старую CMS или самописный код, который переписывать долго и дорого. В таком случае есть временные меры, но важно понимать: это отсрочка, а не решение.

Некоторые дистрибутивы Linux выпускают собственные исправления для своих пакетов PHP 7.4, а ряд компаний предлагает коммерческую расширенную поддержку устаревших веток, например TuxCare и Zend. Дополнительно стоит закрыть сайт веб-application firewall, ограничить доступ к админке по IP, регулярно делать бэкапы и отслеживать целостность файлов.

Параллельно составьте план миграции с конкретными сроками. Чем дольше проект живёт на старой версии, тем больше накапливается «технический долг» и тем дороже обходится итоговый переход.