Как узнать версию PHP на сервере и безопасно её обновить

PHP обновляют редко и неохотно: сайт работает — зачем трогать. Но каждая ветка PHP получает исправления безопасности только ограниченное время, а критические уязвимости вроде PHP2Shell в октябре 2026 года показывают, что обновление иногда нужно сделать в тот же день. Разберём по шагам, как узнать, какая версия PHP на самом деле обслуживает ваш сайт, и как перейти на новую так, чтобы ничего не сломать.

Какие версии PHP поддерживаются сейчас

У каждой ветки PHP два года активной поддержки и ещё два года — только исправления безопасности. По данным php.net на октябрь 2026 года:

• PHP 8.5 — активная поддержка до 31 декабря 2027, безопасность до 31 декабря 2029.
• PHP 8.4 — активная поддержка до 31 декабря 2026, безопасность до 31 декабря 2028.
• PHP 8.3 — только безопасность, до 31 декабря 2027.
• PHP 8.2 — только безопасность, до 31 декабря 2026. Через два месяца ветка перестанет получать исправления.
• PHP 8.1 и старше — поддержка закончилась (8.1 — 31 декабря 2025). Исправлений от проекта PHP больше нет.

Если у вас 8.2 или старше, обновление стоит планировать уже сейчас. Для новых проектов разумный выбор — 8.4 или 8.5, если их поддерживает ваша платформа.

Шаг 1. Узнать версию — правильно

Самая частая ошибка — выполнить php -v в консоли и решить, что сайт работает на этой версии. На сервере может стоять несколько версий PHP одновременно: консольная (CLI) и та, что обрабатывает веб-запросы (PHP-FPM или модуль Apache), нередко различаются. Проверять нужно обе.

• Консоль: php -v показывает версию CLI. Ею выполняются cron-задачи, очереди, composer, bin/magento и artisan.
• Веб-сервер: временно положите в корень сайта файл с <?php phpinfo(); под случайным именем, откройте его в браузере и посмотрите строки PHP Version и Server API. Сразу после проверки файл удалите: phpinfo раскрывает пути, модули и настройки сервера.
• Список установленных версий на Debian и Ubuntu: ls /etc/php/; запущенные пулы FPM: systemctl list-units 'php*-fpm*'.

Без доступа к серверу версию подскажет сама платформа:

• WordPress: «Инструменты → Здоровье сайта → Информация → Сервер».
• Laravel: php artisan about выводит версию PHP и окружение.
• Magento: bin/magento --version покажет версию Magento, а версию PHP веб-сервера — phpinfo или панель хостинга.
• cPanel и Plesk: версия PHP задаётся для каждого сайта отдельно — в MultiPHP Manager (cPanel) или в настройках PHP домена (Plesk).

Шаг 2. Понять, как PHP подключён

Строка Server API в phpinfo показывает режим работы: FPM/FastCGI — отдельный сервис PHP-FPM, к которому обращается nginx или Apache; Apache 2.0 Handler — mod_php, PHP внутри процессов Apache. От режима зависит, что переключать и что перезапускать. mod_php — устаревшая схема: при переходе на новую версию разумно сразу перейти на PHP-FPM.

Шаг 3. Проверить совместимость

Новая версия PHP должна подходить вашей платформе и всем модулям:

• Magento: по требованиям Adobe, 2.4.9 работает на PHP 8.5, 2.4.8 — на 8.4 и 8.3, 2.4.7 — на 8.3 и 8.2. Иногда сначала нужно обновить сам Magento, и только потом PHP.
• WordPress рекомендует PHP 8.3 и новее. Отдельно проверьте тему и плагины: проблемы обычно в них, а не в ядре.
• Laravel 12 поддерживает PHP 8.2–8.5, Laravel 11 — до 8.4, и с марта 2026 года он уже не получает исправлений безопасности.
• Зависимости Composer: composer why-not php 8.4 покажет пакеты, которые не пускают на новую версию.
• Расширения PHP: сохраните список php -m — на новой версии нужно поставить те же модули (intl, gd, soap, bcmath, redis, imagick и т. д.).

Шаг 4. Подготовиться

1. Сделайте резервную копию файлов и базы данных.
2. Сохраните текущие настройки: php.ini, пулы FPM (на Debian и Ubuntu — /etc/php/8.2/fpm/pool.d/), конфигурацию веб-сервера.
3. Прогоните обновление сначала на тестовой копии сайта: каталог, корзина, оформление заказа, вход в админку, отправка писем, импорт и cron.
4. Включите логирование ошибок и deprecation-предупреждений — они подскажут, что править в коде.

Шаг 5. Обновить

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

• Ubuntu: актуальные сборки PHP публикует репозиторий Ондржея Сури: sudo add-apt-repository ppa:ondrej/php, затем sudo apt install php8.4-fpm php8.4-cli и нужные расширения, например php8.4-mysql php8.4-intl php8.4-gd php8.4-xml php8.4-mbstring php8.4-curl php8.4-zip. Для Debian тот же автор ведёт репозиторий packages.sury.org.
• RHEL, AlmaLinux, Rocky: репозиторий Remi. Подключите remi-release для своей версии системы, затем dnf module reset php и dnf module enable php:remi-8.4, после чего dnf update. Если нужно держать две версии параллельно, у Remi есть отдельные пакеты вида php84.
• Docker: поменяйте базовый образ, например FROM php:8.2-fpm на FROM php:8.4-fpm, и пересоберите расширения. Даже если версия не меняется, пересоберите образ с --pull: теги вида 8.4-fpm обновляются с каждым патч-релизом, и только так вы получите исправления безопасности.
• Панели хостинга: в cPanel и Plesk версия выбирается для сайта в настройках PHP. Сначала переключите тестовый поддомен.

Шаг 6. Переключить сайт

1. Перенесите свои значения из старого php.ini и пула FPM в новые: memory_limit, max_execution_time, upload_max_filesize, настройки OPcache и пользователя пула.
2. nginx: поменяйте сокет в fastcgi_pass, например на unix:/run/php/php8.4-fpm.sock, проверьте конфигурацию nginx -t и перезагрузите nginx.
3. Apache с FPM: a2disconf php8.2-fpm, a2enconf php8.4-fpm, затем systemctl reload apache2. Если был mod_php — a2dismod php8.2 и a2enmod php8.4, но лучше в этот момент перейти на FPM.
4. CLI: на Debian и Ubuntu — update-alternatives --set php /usr/bin/php8.4. Не забудьте cron, очереди и supervisor: в них часто прописан полный путь к старому бинарнику.
5. Перезапустите все процессы PHP: systemctl restart php8.4-fpm, воркеры очередей (php artisan queue:restart, consumers Magento) и сбросьте кеши приложения.

Шаг 7. Проверить

• Снова откройте временный phpinfo (и удалите его) — версия и Server API должны быть новыми.
• Пройдите ключевые сценарии: главная, поиск, карточка товара, корзина, оплата, личный кабинет, админка.
• Первые часы следите за логами PHP-FPM, веб-сервера и приложения: фатальные ошибки и deprecation-предупреждения появляются на редких страницах не сразу.
• Проверьте, что cron и очереди отработали на новой версии.

Если что-то пошло не так

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

Когда обновлять

Минорные обновления внутри ветки (например, 8.4.26 → 8.4.27) несут исправления ошибок и уязвимостей — их стоит ставить сразу. Переход на новую ветку (8.2 → 8.4) планируйте заранее, до окончания поддержки. А когда выходит критическое исправление, как с PHP2Shell, обновление в тот же день важнее любых планов.

Мы работаем с PHP, Magento, Laravel и WordPress больше десяти лет. Проверим, какая версия PHP и в каком режиме работает на ваших серверах, обновим её на тестовой копии, выкатим на продакшен с планом отката, а старые проекты переведём на поддерживаемую версию.

Источники: поддерживаемые версии PHP, неподдерживаемые ветки PHP, системные требования Adobe Commerce, требования WordPress, политика поддержки Laravel, PPA ondrej/php, репозиторий Sury для Debian, репозиторий Remi, официальный образ PHP в Docker Hub.