Как обновить PHP на хостинге и в WordPress без поломки сайта

21 октября 2026 года команда PHP выпустила внеплановые версии 8.5.12, 8.4.27, 8.3.36 и 8.2.35. Они закрывают две критические уязвимости PHP2Shell, через которые код на сервере можно выполнить без авторизации, — подробности в нашей новости о PHP2Shell. Обновление WordPress и плагинов от этих дыр не спасает: ошибка сидит в самом интерпретаторе. Для PHP 7.4–8.1 проект PHP выложил лишь минимальные патчи в исходниках, для 7.3 и старше — ничего, и надёжный выход один: перейти на поддерживаемую ветку.

Ниже — как обновить PHP на WordPress и на хостинге без белого экрана: кто за что отвечает, какую версию выбрать, как подготовить бэкап и копию сайта, где переключается версия в Beget, Timeweb, REG.RU, ISPmanager, cPanel и Plesk и как откатиться, если что-то сломалось. Шаги панелей редакция сверила с официальной документацией провайдеров и разработчиков на 22.10.2026.

Кто обновляет PHP на хостинге, а кто — владелец сайта

На виртуальном хостинге работа делится на две части. Провайдер собирает PHP, ставит патчи безопасности и решает, какие ветки вообще доступны. Владелец сайта выбирает ветку в панели: 7.4, 8.2, 8.3 и так далее. Патч внутри ветки, например переход с 8.3.35 на 8.3.36, хостер ставит сам. Переход с 8.1 на 8.3 без вашего клика обычно не происходит: он может сломать сайт. Исключение — когда провайдер убирает старые ветки из списка: NetAngels 21.10.2026 объявил, что скоро уберёт из выбора 7.0–7.3 и 8.0–8.1.

После PHP2Shell это разделение провайдеры подтвердили публично. Beget в обновлении от 22.10.2026 сообщил, что на виртуальном хостинге и администрируемых серверах обновил все доступные пользователям версии PHP и снял временные ограничения, а владельцам облачных серверов, которые администрируют их сами, нужно обновить PHP самостоятельно. Спринтхост в Telegram написал, что на серверах ограничил потенциально уязвимые механизмы и ставит обновления, а владельцам Спринтбоксов обновлять PHP самим. Timeweb Cloud посоветовал обновить PHP, перезапустить PHP-FPM и временно отключить upload_progress; про свой shared-хостинг компания в этом посте не пишет. Подробнее о том, чем shared отличается от VPS по зоне ответственности, — в сравнении shared-хостинга и VPS.

На VPS, который вы администрируете сами, обновления PHP обеспечивает владелец: через средства панели (ISPmanager, FASTPANEL, Plesk) или пакетами системы — в зависимости от установки. Для этого случая у нас будет отдельная инструкция — как обновить PHP на VPS.

Какую версию PHP выбрать в октябре 2026

Готовые исправленные релизы PHP2Shell вышли только для поддерживаемых веток 8.2–8.5. По бюллетеню PHP от 21.10.2026, версии 8.1 и старше обновлений от проекта больше не получают: для 7.4, 8.0 и 8.1 опубликованы только минимальные патчи в исходниках, а готовые сборки зависят от дистрибутивов и хостеров. Сроки поддержки взяты с php.net/supported-versions, совместимость с WordPress — из таблицы разработчиков WordPress, обе проверены 22.10.2026.

WordPress на странице системных требований рекомендует PHP 8.3 или новее. На 8.2 переходить можно, но уже через два с небольшим месяца придётся обновляться снова: поддержка ветки заканчивается 31 декабря 2026 года. Для большинства сайтов на WordPress разумная цель — 8.3, а 8.4 и 8.5 — если тема и плагины свежие и уже проверены на этих версиях.

Для 1С-Битрикс правила жёстче. В справке Битрикс24 (обновлена 24.08.2026) сказано, что с 01.02.2026 поддержка продуктов на PHP ниже 8.2 ограничена, рекомендуемая версия — 8.3 или выше, а обновления коробочных версий без PHP 8.2 установить нельзя. Хостинги под эту CMS собраны в разделе хостинга для Битрикс.

Подготовка: бэкап и обновление плагинов до смены PHP

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

Если у хостинга есть SSH, копию можно снять за пару минут. Имя базы, пользователя, пароль и адрес сервера БД берите из wp-config.php (константы DB_NAME, DB_USER, DB_PASSWORD, DB_HOST), путь к папке сайта — свой (на Beget это, например, ~/site.ru/public_html). Если в DB_HOST указан порт или сокет, передайте его через -P или --socket. Метка времени в имени файла не даст повторному запуску затереть прошлую копию:

# Уникальная метка для этого запуска
TS=$(date +%F-%H%M%S)

# Архив файлов сайта
tar czf ~/site-files-$TS.tar.gz -C ~/site.ru public_html && echo "files OK"

# Дамп базы: адрес сервера БД — из DB_HOST, пароль запросит команда
mysqldump -h АДРЕС_БД -u ИМЯ_ПОЛЬЗОВАТЕЛЯ -p ИМЯ_БАЗЫ > ~/site-db-$TS.sql && echo "db OK"

# То же через WP-CLI, если он есть на хостинге (данные подключения он берёт из wp-config.php)
cd ~/site.ru/public_html && wp db export ~/site-db-$TS.sql

# Убедиться, что копии не пустые
ls -lh ~/site-files-$TS.tar.gz ~/site-db-$TS.sql

Переходить к смене PHP стоит, только если обе команды завершились без ошибок и файлы в списке имеют ненулевой размер.

Второй шаг подготовки — обновить WordPress, тему и плагины на текущей версии PHP и убедиться, что сайт работает. Этот порядок советует сам WordPress в инструкции «Update PHP»: старые версии плагинов чаще всего и ломаются на новом PHP, а свежие обычно уже адаптированы. Через WP-CLI это три команды:

wp core update
wp plugin update --all
wp theme update --all

Плагины и темы, которые не обновлялись несколько лет или куплены вне каталога WordPress, выпишите отдельно — их проверяют первыми.

Как проверить совместимость плагинов и темы

Текущую версию PHP показывает сам WordPress: «Инструменты» → «Здоровье сайта» → вкладка «Информация» → раздел «Сервер». На вкладке «Состояние» при устаревшем PHP появляется критическая проблема с пометкой «Безопасность» — так описано в документации экрана Site Health. Как узнать версию другими способами, разберём в гайде как узнать версию PHP.

Плагин PHP Compatibility Checker, который до сих пор советуют во многих инструкциях, на 22.10.2026 больше не развивается: на его странице в каталоге сказано, что новых релизов, включая исправления безопасности, не будет, а проверка, судя по описанию, доходит только до PHP 8.0. Код он не выполняет и даёт ложные срабатывания. Для перехода на 8.2–8.5 на него полагаться нельзя. Разработчикам подойдёт открытый набор правил PHPCompatibility для PHP_CodeSniffer, но и он ищет проблемы в коде статически. Надёжная проверка одна — запустить сайт на новой версии и пройти его руками.

Что именно ломается при переходе, видно в официальных руководствах по миграции. В PHP 8.0 удалены функции create_function(), each(), money_format(), get_magic_quotes_gpc() — вызов любой из них приведёт к фатальной ошибке, если плагин не предусмотрел совместимый вариант. В PHP 8.2 объявлены устаревшими динамические свойства и utf8_encode(): по умолчанию такие уведомления не останавливают выполнение, но при включённом журналировании повторяющиеся сообщения могут раздувать лог. Изменения следующих веток — в руководствах по 8.3, 8.4 и 8.5.

Тест на копии сайта

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

1. Создайте поддомен, например test.site.ru, и закройте его от индексации паролем на каталог.
2. Разверните на нём копию сайта вручную из бэкапа: файлы — в папку поддомена, дамп — в отдельную базу, в wp-config.php копии — данные новой базы, адрес сайта — адрес поддомена.
3. Для копии выберите в панели новую версию PHP и убедитесь, что у боевого сайта версия осталась прежней. Плагины клонирования вроде WP Staging в бесплатной версии кладут копию в подкаталог основного сайта, а у подкаталога отдельную версию PHP задать обычно нельзя — для этой проверки нужен именно поддомен.
4. Включите журнал ошибок в wp-config.php копии.
5. Пройдите главные сценарии: главная, записи, поиск, формы, корзина и оплата, вход в админку, сохранение записи.
6. Прочитайте wp-content/debug.log: фатальные ошибки чинят до переключения боевого сайта, предупреждения Deprecated — по мере обновления плагинов.

Константы для журнала даёт руководство разработчика WordPress; вставлять их перед строкой «That’s all, stop editing!». На рабочем сайте их держать не стоит: документация прямо не рекомендует отладку на живых сайтах, а журнал может содержать чувствительные данные.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Как сменить версию PHP в панели хостинга

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

Beget

Чтобы обновить PHP на Beget, по инструкции хостера от 21.10.2026 нужно пройти путь «Сайты» → «Управление сайтами» → значок шестерёнки справа от домена → выбрать версию PHP 8.2 или новее → применить. Обновление, по словам хостера, обычно занимает до 10 минут; версию проверяют отдельно для каждого домена и поддомена. В базе знаний тот же раздел описан с кнопкой «PHP» напротив сайта. Общий php.ini на виртуальном хостинге один для всех клиентов сервера, его не редактируют, а параметры меняют через .htaccess. Для заданий cron версию задают путём к интерпретатору вида /usr/local/php-cgi/ВЕРСИЯ/bin/php. Тарифы — в карточке Beget.

Timeweb

По справке Timeweb: раздел «Сайты» → навести курсор на сайт и нажать шестерёнку → в блоке «Настройки версии и кодировки» нажать «Настроить» → выбрать версию и сохранить. Список версий зависит от ОС сервера: на Ubuntu 22.04 доступны 7.4–8.5, на Ubuntu 18.04 — 5.3–8.3. Если нужной версии нет, справка предлагает написать в поддержку: аккаунт перенесут на сервер, где она есть. В консоли версию выбирают путём /opt/php83/bin/php. Подробнее о хостере — в карточке Timeweb.

REG.RU

Хостинг REG.RU работает на ISPmanager. По справке REG.RU: раздел «Сайты» → двойной клик по домену → в поле «Версия PHP (CGI)» выбрать версию → «Ok». Сборки с суффиксом -bx- предназначены для 1С-Битрикс и идут без ionCube, а суффикс -ioncube нужен для зашифрованных ionCube скриптов на версиях выше 8.0. На тарифе «Хост-Лайт» PHP нет. Карточка провайдера — REG.RU в каталоге.

ISPmanager на своём VPS

В документации ispmanager 6 альтернативная версия ставится через «Settings» → «Software Configuration» → «Alternative version of PHP» и попадает в /opt/. Дальше всё зависит от режима PHP. В режиме модуля Apache администратор выбирает версию для всех доменов этого режима. В режиме FastCGI (Nginx + PHP-FPM) версия меняется в списке PHP на уровне пользователя и действует на все его домены. Beget для своих VPS с ispmanager описывает короче: «Сайты» → выбрать сайт → «Изменить параметры сайта» → версия 8.2 или новее. Версию PHP из репозитория ОС панель не меняет — она обновляется пакетами системы. Что это за панель и чем её заменить — в обзоре ISPmanager.

FASTPANEL

Шаги из той же инструкции Beget: «Настройки» → «Приложения» → установить нужную версию PHP, если её нет → открыть карточку сайта → в настройках выбрать новую версию → сохранить.

cPanel

Версия меняется в MultiPHP Manager. По документации cPanel (страница обновлена 08.07.2026): отметить домен → выбрать версию в меню «PHP Version» → «Apply». EasyApache 4 поддерживает PHP 7.4 и 8.1–8.5, рекомендованные администратором версии помечены «Recommended». Если домен стоит в режиме «inherit», он берёт системную версию сервера — её меняет только администратор. Нет нужной версии в меню — она не установлена на сервере или недоступна вашему аккаунту.

Plesk

По документации Plesk Obsidian: «Websites & Domains» → найти домен → «PHP» → отметить «PHP support», если галочка снята → выбрать версию и тип обработчика → «OK». Plesk сам предупреждает, что разные версии PHP совместимы не на 100%. Отсутствие нужной версии в меню документация советует решать через хостинг-провайдера.

Когда всё переключено, убедитесь, что сайт реально работает на новой версии, а не на старой из кэша или из консоли. Через SSH это делается временным файлом, который потом нужно удалить:

echo '<?php echo PHP_VERSION;' > ~/site.ru/public_html/ver-check.php
curl -s https://site.ru/ver-check.php; echo
rm ~/site.ru/public_html/ver-check.php

# Версия PHP в консоли может отличаться от версии сайта
php -v

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

Ошибки после переключения и откат

Если сайт упал после смены PHP, первым делом верните прежнюю версию тем же путём в панели — так советуют и Timeweb, и WordPress. Возврат может восстановить работу, если причина только в несовместимости кода с новой версией; время применения зависит от хостинга, а изменения в базе и файлах откат не отменит. Причину потом ищут на копии. Учтите нюанс PHP2Shell: откатываться стоит только на сборку с подтверждёнными исправлениями. Неисправленная 8.2–8.5 возвращает уязвимость, для 7.4, 8.0 и 8.1 проект PHP выложил лишь минимальные патчи в исходниках, для 7.3 и старше — ничего, так что защищённость старой ветки зависит от сборки хостера.

С версии 5.2 у WordPress есть режим восстановления: при фатальной ошибке посетители видят сообщение о технических неполадках, а на почту администратора приходит письмо со ссылкой, по которой можно войти в админку и отключить сломавший сайт плагин, — механизм описан в заметке разработчиков ядра. Если письмо не пришло, плагин отключают по SSH. Must-use плагины из wp-content/mu-plugins WP-CLI загружает даже с --skip-plugins — так сказано в справочнике WP-CLI, их отключают только переименованием файла.

cd ~/site.ru/public_html

# Через WP-CLI: не загружать плагины и темы, иначе команда упадёт на той же ошибке
wp --skip-plugins --skip-themes plugin deactivate ИМЯ_ПЛАГИНА

# Без WP-CLI: переименовать папку плагина, WordPress его отключит
mv wp-content/plugins/ИМЯ_ПЛАГИНА wp-content/plugins/ИМЯ_ПЛАГИНА.off

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

Если хостер не даёт PHP 8.2 и новее

Старая ветка в списке панели ещё не значит, что сайт беззащитен: Beget, например, пишет, что обновил «все версии PHP доступные пользователям», включая самые старые. Но проект PHP эти ветки не поддерживает, и доступность исправлений зависит от поставщика сборки — хостера, дистрибутива или LTS-вендора — и от условий поддержки. Порядок действий такой:

1. Спросите поддержку, есть ли сервер с новыми версиями. Timeweb, например, в справке прямо предлагает перенос аккаунта на сервер, где нужная версия есть.
2. Уточните, пропатчена ли ваша текущая сборка после релиза 21.10.2026, и попросите ответ письменно в тикете.
3. Если новых версий нет и не будет — меняйте хостинг. Провайдеры с PHP 8.x собраны в каталоге хостинга для PHP и в подборке хостинга для WordPress, а как переехать без простоя, мы описали в гайде о переносе сайта на другой хостинг.
4. Вариант для тех, кто готов администрировать сам, — VPS с актуальной ОС, но тогда и патчи PHP становятся вашей обязанностью.

До переезда остаются временные меры, и все они слабее обновления. В бюллетене PHP прямо сказано, что полных обходных решений нет и безопасный путь один — обновиться. Cloudflare 21.10.2026 включил защитные правила WAF по умолчанию, в том числе на бесплатном тарифе; на платных стоит проверить, что набор правил работает в режиме блокировки, — по блогу Cloudflare. Правила фильтруют только трафик, который идёт через Cloudflare, и не помогают, если сервер доступен напрямую по IP. CISA для серверов, которые нельзя обновить, и для PHP 8.1 и старше советует убрать их из интернета.

Короткий план на сегодня

1. Сразу подтвердить у хостера, что исправления PHP2Shell установлены: нужны 8.2.35, 8.3.36, 8.4.27, 8.5.12 или сборка с подтверждённым бэкпортом. Это срочный шаг, его не откладывают до смены ветки.
2. Посмотреть версию PHP в «Здоровье сайта» или в панели хостинга.
3. Отдельным шагом спланировать смену ветки: с 8.1 и ниже — на 8.3; с 8.2 — до 31.12.2026, когда закончится её поддержка.
4. Снять бэкап файлов и базы, обновить WordPress, тему и плагины.
5. Поднять копию на поддомене, переключить на ней PHP, прочитать журнал ошибок.
6. Переключить боевой сайт в панели и проверить реальную версию.
7. При поломке — откат в панели, разбор на копии, повторное переключение.

Владельцам VPS тот же план выполняется командами системы — его разберём в отдельной инструкции. Если сервер уже вёл себя странно на этой неделе, проверьте его по чек-листу из материала о взломе сайта на WordPress, а заодно прочитайте о соседнем инциденте — атаке на VMmanager 6 у FirstVDS.