Обновление версии PHP: как не сломать сайт

Почему устаревшая версия PHP — это не только вопрос производительности

У каждой ветки PHP есть официально объявленный жизненный цикл: период активной поддержки с выпуском новых функций и исправлений, затем период поддержки только критических уязвимостей безопасности, и наконец полное прекращение поддержки (End of Life). После этой даты разработчики PHP больше не выпускают патчей — ни для новых уязвимостей, ни для критических ошибок, обнаруженных уже после окончания поддержки.

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

Помимо безопасности, между мажорными версиями PHP накапливаются заметные улучшения производительности — переход, например, с PHP 7.4 на актуальную ветку 8.x на типичном CMS-проекте нередко даёт прирост скорости генерации страницы на десятки процентов без единой строчки изменений в коде, просто за счёт более эффективного движка интерпретатора.

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

Практическое наблюдение в сопровождении PHP-проектов

Эта статья разбирает практический план перехода на новую версию PHP без риска для работающего сайта: от проверки текущего состояния до параллельной установки, тестирования совместимости, самого переключения и плана отката на случай непредвиденных проблем.

Шаг первый: инвентаризация текущего состояния

Прежде чем что-либо менять, нужно точно зафиксировать, что установлено сейчас, — версию самого PHP и полный список подключённых расширений, от которых может зависеть работа CMS, отдельных плагинов или собственного кода проекта.

php -v
php -m

Отдельно стоит выяснить, объявлена ли текущая версия официально вышедшей из поддержки (End of Life) — эта информация публикуется на официальном сайте проекта PHP и обновляется по мере выхода новых веток; если версия уже не поддерживается или поддержка заканчивается в ближайшие месяцы, откладывать обновление дальше не имеет смысла с точки зрения безопасности.

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

Шаг второй: установка новой версии параллельно со старой

Ключевой принцип безопасного обновления — не заменять текущую версию PHP новой, а установить новую версию рядом со старой, оставив обе физически присутствующими на сервере одновременно. На Ubuntu и Debian это делает возможным репозиторий Ondřej Surý (ppa:ondrej/php), содержащий пакеты для нескольких версий PHP одновременно, каждая со своим независимым набором пакетов.

add-apt-repository ppa:ondrej/php
apt update
apt install php8.3-fpm php8.3-mysql php8.3-gd php8.3-mbstring php8.3-curl php8.3-zip php8.3-opcache -y

После установки в системе одновременно присутствуют, например, php8.2-fpm и php8.3-fpm — каждый со своим сокетом, своей конфигурацией пула и своим набором расширений, никак не мешая друг другу. Старый сайт продолжает работать через старый сокет ровно так же, как и до этой установки, поскольку конфигурация Nginx всё ещё указывает именно на него.

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

Шаг третий: сверка расширений между версиями

Список подключённых расширений для новой версии по умолчанию не обязан совпадать со списком для старой — некоторые пакеты могли быть установлены на старую версию вручную в разное время и забыты, а часть расширений могла быть переименована или объединена в новых версиях PHP.

diff <(php8.2 -m | sort) <(php8.3 -m | sort)

Каждое расширение, присутствующее в старой версии, но отсутствующее в новой, стоит явно доустановить — недостающее расширение обычно проявляется не сразу при запуске сайта, а в конкретном месте кода, обращающемся к нему (например, работа с изображениями через GD, кэширование через Redis-расширение, работа с XML), что усложняет диагностику, если проблему не отловить заранее именно на этом этапе.

Шаг четвёртый: проверка кода на устаревшие функции

Между мажорными версиями PHP регулярно происходит вывод из употребления (deprecation) части функций и изменение поведения некоторых языковых конструкций — код, написанный несколько лет назад, вполне может использовать функции, которые в новой версии либо выдают предупреждение, либо были удалены полностью и вызывают фатальную ошибку.

error_reporting(E_ALL);
ini_set('display_errors', '1');

Включать полное отображение ошибок стоит только на staging-окружении, а не на боевом сайте — на production подобные предупреждения должны попадать в лог, а не показываться реальным посетителям, что регулируется теми же настройками display_errors и log_errors в php.ini.

Для сторонних плагинов и тем CMS дополнительно стоит свериться с их официальной документацией или changelog на предмет заявленной поддержки конкретной версии PHP — плагин, давно не обновлявшийся автором, может попросту не тестироваться разработчиком на новых версиях языка, и тогда проблему придётся либо чинить самостоятельно, либо искать альтернативный плагин.

Полезный практический инструмент — статические анализаторы совместимости версий PHP (например, PHPCompatibility как набор правил для PHP_CodeSniffer), которые сканируют весь код проекта и составляют список потенциально проблемных мест до реального запуска на новой версии, а не по факту появления ошибки у живого посетителя сайта.

Шаг пятый: тестирование на staging перед боевым переключением

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

Практический способ организовать такое окружение без создания отдельного сервера — настроить на том же сервере тестовый сайт на альтернативном порту или поддомене, использующий новый пул PHP-FPM, работающий параллельно с боевой версией сайта, использующей старый пул.

На staging стоит целенаправленно пройти не только главную страницу, но и ключевые пользовательские сценарии — оформление заказа в интернет-магазине, отправку формы, авторизацию, административную панель CMS — именно в этих местах чаще всего скрываются функции, редко вызываемые при беглом просмотре сайта, но критичные для реальной работы бизнеса.

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

Шаг шестой: само переключение — смена пула, на который указывает Nginx

Когда тестирование на staging завершено успешно, переключение боевого сайта на новую версию PHP сводится к изменению одной директивы в конфигурации Nginx — пути к сокету в fastcgi_pass, подробно устройство этой связки разобрано в отдельной статье базы знаний.

# было
fastcgi_pass unix:/run/php/php8.2-fpm.sock;

# стало
fastcgi_pass unix:/run/php/php8.3-fpm.sock;

nginx -t && systemctl reload nginx

Команда nginx -t перед перезагрузкой обязательна — она проверяет синтаксис изменённой конфигурации, не применяя её, и позволяет отловить опечатку в пути к сокету до того, как она реально повлияет на работающий сайт. systemctl reload, в отличие от restart, применяет новую конфигурацию без разрыва уже установленных соединений, что делает само переключение практически незаметным для посетителей, находящихся на сайте в этот момент.

Сразу после переключения стоит открыть сайт вживую и явно проверить, что PHP-код действительно выполняется через новый пул, а не через старый по ошибке, — например, временно добавив вывод phpversion() на тестовой странице или сверившись с версией через заголовок ответа сервера, если она не скрыта из соображений безопасности.

Шаг седьмой: план отката, если что-то пошло не так

Главное практическое преимущество параллельной установки версий — откат так же прост, как и само переключение: поскольку старая версия PHP-FPM осталась установленной и её пул продолжает существовать, достаточно вернуть предыдущее значение fastcgi_pass в конфигурации Nginx и снова выполнить reload.

fastcgi_pass unix:/run/php/php8.2-fpm.sock;
# nginx -t && systemctl reload nginx

Разумная практика — держать оба пула PHP-FPM (старый и новый) запущенными в течение нескольких недель после переключения, а не отключать и тем более не удалять старую версию сразу же после первого успешного просмотра сайта. За этот период проявляются проблемы, которые не всегда видны сразу — редко используемый раздел админки, ежемесячная фоновая задача, сезонный сценарий вроде оформления возврата товара.

Перед самим переключением на боевом сервере также стоит убедиться в наличии свежей резервной копии базы данных и файлов сайта — обновление версии PHP само по себе не затрагивает данные, но при выявленных проблемах с плагинами, вносящими изменения в структуру базы данных при первом запуске под новой версией, откат может потребовать восстановления не только конфигурации Nginx, но и самих данных.

Отдельная деталь, которую часто забывают: cron и консольные команды

Веб-запросы через Nginx — не единственное место, где используется PHP. Задачи по расписанию, вызывающие интерпретатор PHP напрямую из командной строки (например, php /var/www/example.ru/cron/import.php), продолжат использовать ту версию PHP, которая стоит по умолчанию в системе или указана явно в самой команде — независимо от того, что уже было переключено в конфигурации Nginx.

which php
php -v
# при необходимости указать версию явно:
# /usr/bin/php8.3 /var/www/example.ru/cron/import.php

После установки новой версии параллельно со старой команда php по умолчанию может по-прежнему указывать на старую версию через системные alternatives — стоит явно проверить это и либо обновить сам alternatives, либо, что надёжнее, прописать полный путь к нужному бинарнику конкретной версии прямо в определении cron-задачи, чтобы переключение версии для веба и для фоновых задач происходило осознанно и раздельно, а не полагалось на системные настройки по умолчанию.

Типичные ошибки при обновлении версии PHP

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

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

Тестирование только главной страницы сайта вместо ключевых пользовательских сценариев — многие проблемы совместимости проявляются именно в специфичных разделах вроде оформления заказа, экспорта данных или административной панели, которые не видны при беглом просмотре.

Забытые cron-задачи, продолжающие вызывать старую версию PHP через путь по умолчанию, — сайт в браузере выглядит полностью рабочим на новой версии, тогда как фоновые процессы продолжают тихо использовать старую, что позже создаёт путаницу при диагностике необъяснимых расхождений в поведении.

Удаление старой версии PHP сразу после первого успешного просмотра сайта — редко используемые сценарии и сезонные функции могут проявить проблему несовместимости через недели после переключения, когда пути назад через простой откат конфигурации уже не остаётся.

Чек-лист безопасного обновления версии PHP

Шаг 1. Зафиксируйте текущую версию PHP, список подключённых расширений и минимальные требования используемой CMS и её плагинов.

Шаг 2. Установите новую версию PHP-FPM параллельно со старой, не удаляя и не отключая текущую рабочую версию.

Шаг 3. Сверьте список расширений между старой и новой версией и доустановите недостающие пакеты.

Шаг 4. Проверьте код проекта и сторонние плагины на использование устаревших или удалённых функций, включив полное отображение ошибок только на тестовом окружении.

Шаг 5. Проведите полноценное тестирование на staging-окружении, включая ключевые пользовательские сценарии и фоновые скрипты, а не только главную страницу.

Шаг 6. Переключите fastcgi_pass в конфигурации Nginx на новый пул и мягко перезагрузите Nginx через systemctl reload.

Шаг 7. Держите старую версию установленной несколько недель после переключения на случай, если потребуется быстрый откат, и явно проверьте версию PHP, используемую в cron-задачах.

Итог: осторожность на каждом шаге, а не героизм за один заход

Обновление версии PHP — это не разовое действие «поставить новый пакет», а последовательность независимо проверяемых шагов, каждый из которых снижает риск того, что боевой сайт окажется недоступен из-за несовместимости. Параллельная установка версий превращает потенциально рискованное обновление в операцию с мгновенным путём отката, если что-то пойдёт не так.

Регулярное, небольшими шагами, обновление версии PHP по мере выхода новых веток обходится в разы дешевле по времени и риску, чем однократный вынужденный переход через несколько мажорных версий сразу, когда откладывать обновление дальше уже невозможно из-за окончания поддержки текущей версии. Если план перехода на новую версию PHP для конкретного проекта вызывает сомнения — оставьте заявку внизу страницы, поможем спланировать и провести обновление без риска для работающего сайта.

Итоговая практическая рекомендация — относиться к версии PHP так же, как к любому другому компоненту production-инфраструктуры: с плановыми, заранее протестированными обновлениями, а не с реакцией по факту окончания официальной поддержки, когда время на спокойное тестирование уже упущено.