Как безопасно обновить PHP-версию на рабочем сайте

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

Безопасное обновление начинается не с переключения версии в панели, а с проверки совместимости проекта.

Зафиксировать текущую версию

Сначала нужно понять, что работает сейчас: версия PHP в вебе, версия PHP в консоли, расширения, настройки и зависимости.

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

Веб-версия и консольная версия могут отличаться. Это особенно важно для cron, очередей и Composer.

Проверить composer.json

Если проект использует Composer, нужно посмотреть ограничение PHP и версии пакетов.

composer check-platform-reqs

В composer.json может быть ограничение:

"require": {
    "php": ">=7.4",
    "yiisoft/yii2": "~2.0.49"
}

Если пакет не поддерживает новую PHP-версию, обновление сервера приведёт к ошибкам. Сначала нужно обновить зависимости на тестовой копии.

Найти deprecated и несовместимости

При переходе между major/minor версиями PHP часть старого кода может начать выдавать warnings, deprecations или fatal errors. На тестовой копии стоит включить подробное логирование и пройти основные сценарии.

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

Показывать ошибки пользователям на production не нужно. На тестовой копии ошибки должны попадать в лог.

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

Сайт может зависеть от расширений PHP: mysqli, pdo_mysql, mbstring, curl, gd, imagick, intl, zip, redis, soap. После переключения версии некоторые расширения могут не быть установлены.

php -m | grep mbstring
php -m | grep curl
php -m | grep redis

Если в вебе модуль есть, а в CLI нет, cron может сломаться даже при работающем сайте.

Тестовая копия

Обновление лучше проверять на копии проекта с актуальной базой и похожими настройками сервера. На тесте нужно пройти реальные сценарии:

• главная и каталог;
• авторизация;
• формы;
• админка;
• оплата или заказ;
• cron и очереди;
• интеграции с внешними API;
• отправка почты.

Проверить cron и демоны

После обновления PHP часто забывают cron. В crontab может быть указан старый путь:

* * * * * cd /var/www/site.ru && /usr/bin/php7.4 yii queue/run

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

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

План отката

Перед production-переключением должен быть понятный откат: как вернуть старую PHP-версию, какие конфиги менять, что делать с Composer, где лежит бэкап.

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

После переключения

Сразу после обновления нужно смотреть логи, а не только открывать главную страницу.

tail -n 150 /var/log/nginx/error.log
tail -n 150 /var/log/php-fpm/error.log
tail -n 150 runtime/logs/app.log

Если используются очереди или systemd-сервисы, их нужно перезапустить и проверить статус.

systemctl status php8.2-fpm
systemctl status site-queue

Чек-лист

1. Зафиксировать текущую PHP-версию и расширения.
2. Проверить PHP в CLI и вебе.
3. Проверить composer.json и composer.lock.
4. Запустить composer check-platform-reqs.
5. Проверить проект на тестовой копии.
6. Проверить cron, очереди и демоны.
7. Подготовить план отката.
8. После переключения проверить логи и основные сценарии.

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