Обновление legacy PHP проекта: пошаговый план

Почему откладывать обновление опасно

Версии PHP 7.4 и старше больше не получают исправлений безопасности. Любая найденная уязвимость остаётся в вашем проекте навсегда. Для интернет-магазина, личного кабинета или CRM это прямой риск утечки данных и простоя.

Есть и менее заметные последствия. Современные библиотеки и SDK платёжных систем, служб доставки и маркетплейсов всё чаще требуют PHP 8 и выше. Разработчиков, которые хотят работать с кодом на PHP 5.x, становится меньше, а их услуги дорожают. Каждый год промедления увеличивает объём работы: накапливаются удалённые функции, изменённое поведение и несовместимые пакеты.

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

Этап нулевой: инвентаризация и подготовка

Прежде чем менять версию, нужно понять, с чем вы имеете дело. Выпишите текущую версию PHP, список подключённых расширений, настройки php.ini, cron-задачи и очереди. Проверьте, что версии зависимостей зафиксированы в composer.lock. Если проект подключает библиотеки вручную, копируя папки в репозиторий, это первая вещь, которую стоит привести в порядок.

Второй шаг — воспроизводимое окружение. Поднимите копию проекта в Docker с той же версией PHP, что и на продакшене, и с копией обезличенной базы данных. Если проект запускается локально и на стейджинге, вы можете безопасно экспериментировать. Заодно выясните, какие страницы и разделы реально используются: статистика из Яндекс Метрики или Google Analytics подскажет, какие сценарии критичны, а какой код давно мёртв и его можно не переносить.

Тесты как страховочная сетка

Legacy-код опасен тем, что никто не помнит, как он должен работать. Поэтому до обновления нужно зафиксировать текущее поведение. Такие тесты называют характеризационными: они не проверяют, правильно ли работает система, а лишь запоминают, как она работает сейчас. Если после смены версии PHP результат изменился, вы увидите это сразу.

Начните с самого ценного: регистрации и входа, оформления заказа, расчёта цен и скидок, генерации документов, интеграций с платёжными системами. Подойдут PHPUnit, Codeception или обычные HTTP-запросы к тестовому стенду с проверкой ответа. Если юнит-тесты написать трудно из-за запутанного кода, начните с сквозных тестов: они грубее, но защищают от самых дорогих ошибок.

Что именно ломается при смене версии

Большинство проблем при обновлении повторяются от проекта к проекту. Это удалённые функции, ужесточённые проверки типов и изменённые правила сравнения значений. Хорошая новость в том, что такие вещи хорошо находятся автоматически. Статический анализатор и PHPCompatibility покажут проблемные места ещё до запуска, а Rector исправит часть из них сам.

В таблице ниже собраны самые частые случаи, с которыми сталкиваются при переходе на PHP 7 и 8.

Зависимости и Composer: обновлять с умом

Нередко именно сторонние пакеты тормозят обновление сильнее, чем собственный код. Библиотека, которую не обновляли пять лет, может не поддерживать PHP 8. Начните с команды composer outdated: она покажет, какие пакеты отстали и насколько. Команда composer audit сообщит об известных уязвимостях. Затем для каждой проблемной библиотеки примите решение: обновить, заменить аналогом или вынести нужную часть в собственный код.

Если проект построен на фреймворке (Laravel, Symfony, Yii) или CMS вроде 1С-Битрикс, сначала сверьтесь с таблицей совместимости версий и требованиями ядра и модулей. Иногда обновление PHP придётся делать вместе с обновлением самого фреймворка, и тогда их тоже нужно разбить на шаги. Параметры platform в composer.json помогут проверить, что зависимости подбираются под целевую версию PHP, а не под ту, что сейчас установлена на сервере.

Как не навредить работающему проекту

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

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

Релиз, мониторинг и SEO-безопасность

Релиз — это не конец работы, а начало наблюдения. Подключите сбор ошибок (например, Sentry или стандартные логи PHP-FPM) и первые дни после выкатки внимательно следите за новыми исключениями, скоростью ответа и потреблением памяти. Если используете blue-green деплой, держите старую версию окружения включённой, пока не убедитесь, что новая стабильна.

Для сайтов, которые приносят органический трафик, важно проверить и поисковую сторону. Смена версии PHP сама по себе не влияет на позиции, но ошибки 5xx, медленные ответы и сбои в формировании страниц могут навредить индексированию. Следите за отчётами Яндекс Вебмастера и Google Search Console: ошибки сервера, статус индексирования, доступность sitemap и robots.txt. Одновременно сравните поведение посетителей в Яндекс Метрике и Google Analytics до и после релиза. Резкое падение конверсии или рост отказов часто указывает на скрытую ошибку в форме или корзине.