Как проверить сайт после обновления версии PHP

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

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

Сначала зафиксировать старое окружение

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

php -v
php -m
php -i | grep memory_limit
php -i | grep max_execution_time
php -i | grep upload_max_filesize

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

Composer и platform

Если проект использует Composer, нужно проверить, какую версию PHP ожидают зависимости. В старых проектах часто нет явного ограничения platform, из-за чего локально зависимости ставятся под одну версию, а сервер работает на другой.

composer validate
composer check-platform-reqs

Для аккуратной фиксации окружения можно использовать platform в composer.json:

{
    "config": {
        "platform": {
            "php": "8.2.0"
        }
    }
}

Это не обновляет сервер само по себе, но делает поведение Composer более предсказуемым.

Deprecated и warning — не просто шум

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

tail -f runtime/logs/app.log
tail -f /var/log/php-fpm/error.log

Типовые места проблем:

• устаревшие сигнатуры методов;
• обращение к массиву как к строке;
• динамические свойства объектов;
• старые библиотеки в vendor;
• нестрогие сравнения, которые начали вести себя заметнее;
• код, завязанный на старые расширения PHP.

Проверить расширения PHP

При смене версии PHP часто забывают включить расширения. Код не менялся, но внезапно пропал intl, mbstring, gd, imagick, curl или pdo_mysql.

php -m | grep mbstring
php -m | grep intl
php -m | grep curl
php -m | grep pdo_mysql

Если проект обрабатывает изображения, отдельно проверяют gd или imagick. Если отправляет запросы во внешние API — curl. Если работает с локалями, форматами дат и транслитерацией — intl.

Проверить основные сценарии

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

1. Открыть главную и несколько внутренних страниц.
2. Войти в админку.
3. Сохранить простую запись.
4. Отправить форму обратной связи.
5. Загрузить файл или изображение, если такая функция есть.
6. Запустить основные консольные команды.
7. Проверить cron и очередь.
8. Посмотреть свежие ошибки в логах.

php yii help
php yii migrate/history
php yii cache/flush-all

Проверить opcache

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

php -i | grep opcache.enable
php -i | grep opcache.validate_timestamps

Если opcache настроен на production-режим с ручным сбросом, после деплоя нужно явно перезапустить PHP-FPM или выполнить сброс opcache доступным способом.

sudo systemctl restart php8.2-fpm

Проверить фоновые задачи

Cron может продолжать запускать старый бинарник PHP. Это частая проблема после обновления версии на сайте: веб работает на PHP 8.2, а фоновые задачи всё ещё идут через php7.4.

crontab -l
which php
php -v

В cron лучше указывать полный путь к нужной версии:

* * * * * cd /var/www/site.ru && /usr/bin/php8.2 yii queue/run >> runtime/logs/cron.log 2>&1

Минимальный чек-лист

• зафиксирована старая версия PHP и список расширений;
• проверены требования Composer;
• включены нужные расширения PHP;
• проверены deprecated, warning и fatal error в логах;
• проверены формы, админка, загрузка файлов и консоль;
• cron запускает правильную версию PHP;
• очищен кэш приложения и проверен opcache;
• есть план отката на предыдущую версию.

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