Обновление PHP на сервере: пошаговая инструкция

Зачем вообще обновлять PHP

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

Если сайт работает на PHP, который снят с поддержки, вы фактически живёте с известными уязвимостями. Автоматические сканеры ботов проверяют такие серверы массово, и взлом нередко происходит не из-за сложной атаки, а просто потому, что версия устарела. Для интернет-магазина или сервиса с личными кабинетами это ещё и риски утечки персональных данных.

Вторая причина — скорость. Уже переход с PHP 5.6 на PHP 7.0 дал примерно двукратный прирост производительности, а последующие ветки 8.x добавили JIT-компиляцию, улучшенный OPcache и более эффективную работу с памятью. На практике это означает меньшую нагрузку на процессор и более быстрый ответ сервера, что важно и для пользователей, и для поисковых систем.

Как видно из графика, версии 7.4 и 8.0 уже вышли из поддержки, а 8.1 приближается к этому рубежу. Если ваш сервер всё ещё работает на одной из них, обновление стоит запланировать в ближайшее время, а не откладывать до первой аварии.

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

Подготовка: что нужно выяснить до начала работ

Главное правило обновления — не трогать боевой сервер вслепую. Сначала нужно понять, что именно у вас установлено. Выполните в консоли `php -v`, чтобы узнать версию PHP для командной строки, и посмотрите, какая версия обслуживает сам сайт: для этого можно временно создать файл с вызовом `phpinfo()` или заглянуть в конфигурацию Nginx или Apache. Версии для CLI и для веб-запросов часто различаются, и это источник многих путаниц.

Затем составьте список расширений, которые использует проект: mysqli или pdo_mysql, curl, mbstring, gd, xml, zip, intl, opcache, imagick и другие. Их нужно будет поставить для новой версии отдельно, иначе сайт упадёт сразу после переключения. Быстро получить список поможет команда `php -m`.

Наконец, изучите требования самого проекта. В файле composer.json есть строка require с ограничением php, у WordPress, Битрикса и других систем публикуются минимальные и рекомендуемые версии. Проверьте и каждый установленный плагин: именно устаревшие дополнения чаще всего ломаются при переходе на новую ветку.

Как выглядят команды на практике

Ниже пример для Ubuntu или Debian. Стандартные репозитории этих систем содержат ограниченный набор версий, поэтому для установки нескольких веток параллельно обычно подключают сторонний репозиторий, который поддерживает Ондржей Сури (Ondřej Surý). Для CentOS, AlmaLinux и Rocky Linux аналогичную роль играет репозиторий Remi. Подключать сторонние источники пакетов стоит только осознанно и в соответствии с политикой безопасности вашей компании.

Обратите внимание, что пакеты расширений называются по номеру версии, например php8.3-mysql. Если забыть хотя бы одно нужное расширение, сайт может выдать белый экран или ошибку 500, поэтому сверяйтесь со списком из предыдущего этапа.

Что чаще всего ломается в коде

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

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

Что проверить для SEO после переключения

Обновление PHP не должно влиять на видимость сайта в поиске, если всё прошло гладко. Но любая ошибка 5xx, пусть даже короткая, заметна для поисковых роботов. Если Яндекс или Google несколько раз подряд получают от сервера ошибку, страницы могут временно выпасть из выдачи или реже обходиться.

После переключения откройте Яндекс Вебмастер и Google Search Console: проверьте разделы со статистикой обхода и ошибками сервера, а также используйте инструмент проверки ответа страницы. Убедитесь, что счётчики Яндекс Метрики и Google Analytics продолжают собирать данные, а формы, цели и электронная коммерция не потеряли событий.

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

План отката на случай проблем

Даже при тщательной подготовке нужно заранее знать, как вернуться назад. Если вы оставили старую версию PHP-FPM установленной, откат сводится к возврату прежнего пути сокета в конфигурации веб-сервера и выполнению команд проверки конфигурации и reload. Это занимает пару минут.

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