Обновление PHP на хостинге: как проверить совместимость CMS

PHP обновляют по шагам: снять полный бэкап, поднять копию сайта на тестовой площадке, переключить там версию, пройти по главным сценариям, посмотреть error_log и только потом трогать боевой сайт. Переход на свежую ветку на том же коде обычно даёт 15-30 процентов по времени генерации страницы.

Хостер прислал письмо: «версия PHP 7.4 больше не поддерживается, переключите сайт до такого-то числа». Или проще, панель управления сама показывает жёлтый значок рядом со старой версией. Переключить одну галочку в панели занимает пять секунд, но именно эти пять секунд чаще всего кладут сайт на белый экран посреди рабочего дня. В статье разберу, зачем вообще обновлять PHP, что на практике ломается при переходе, как проверить сайт заранее и что делать, если после переключения всё-таки полыхнуло.

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

Три причины, и все три не абстрактные.

Скорость. Каждая мажорная версия PHP со времён седьмой ветки заметно быстрее предыдущей на типовых задачах CMS: разбор шаблонов, работа с массивами, обращения к базе через ORM. Переход с PHP 7.4 на 8.2 на одном и том же коде без единой правки обычно даёт 15-30 процентов по времени генерации страницы. Это бесплатное ускорение, которое не требует переписывать код.

Безопасность. У версий PHP есть срок жизни: сначала активная поддержка с багфиксами и новыми фичами, потом только security-патчи, потом полный конец поддержки. PHP 7.4 закончил жизнь ещё в конце 2022 года, любая уязвимость в интерпретаторе после этой даты закрываться не будет никогда. Держать боевой сайт на мёртвой версии PHP — это то же самое, что не обновлять WordPress годами, только дыра не в CMS, а в самом языке, на котором всё написано.

Поддержка плагинов и тем. Разработчики популярных плагинов рано или поздно перестают тестировать код на старых версиях PHP и указывают минимальную поддерживаемую версию в требованиях. WooCommerce, Yoast, Rank Math регулярно поднимают планку. Остаться на старой версии PHP означает медленно терять возможность обновлять сам сайт.

Что ломается на практике

Каждая мажорная версия PHP что-то удаляет или ужесточает. Вот что реально встречал на клиентских сайтах при переходе с 7.x на 8.x.

Устаревшие функции. create_function() и each() убраны ещё в PHP 8.0. Если в теме десятилетней давности или в кастомном коде от прошлого подрядчика они использовались, сайт падает сразу с фатальной ошибкой на строке вызова.

Конфликт имён функций. В PHP 8.0 появились встроенные str_contains(), str_starts_with(), str_ends_with(). Старый код, написанный под PHP 7.2, часто содержал самодельные полифиллы с точно такими же именами функций «на всякий случай». Итог: Fatal error: Cannot redeclare str_contains(). Ошибка выглядит загадочно, если не знать, откуда она берётся, а причина ровно в этом.

Динамические свойства объектов. С PHP 8.2 присвоение значения незаявленному свойству объекта помечено как deprecated, в логах начинают сыпаться сотни предупреждений, а в будущих версиях языка это станет полноценной ошибкой. Старый ООП-код без объявленных свойств класса продолжает работать, но забивает error_log мусором так, что реальные проблемы в нём тонут.

Строгая типизация внутренних функций. Передача null туда, где раньше не глядя принимался пустой параметр (например, в trim(), strtolower()), с PHP 8.1 помечена как deprecated, а в некоторых сборках уже возвращает предупреждение прямо в вывод страницы, перед HTML. Так на верстке появляются странные строки текста над шапкой сайта.

Кастомный код от прошлого подрядчика — отдельная категория риска. Обычно это самое слабое место, потому что о его существовании и логике никто уже не помнит, а тестов на него, разумеется, никогда не писали.

Проверка до переключения

Не переключайте версию вслепую на боевом сайте. Три шага, которые снимают большую часть риска.

PHP Compatibility Checker

Статический анализатор кода, который ищет именно такие несовместимости, не запуская сайт целиком. Устанавливается через Composer поверх PHP_CodeSniffer:

composer require --dev squizlabs/php_codesniffer
composer require --dev phpcompatibility/php-compatibility
vendor/bin/phpcs --config-set installed_paths vendor/phpcompatibility/php-compatibility
vendor/bin/phpcs -p wp-content/themes/moya-tema --standard=PHPCompatibility --runtime-set testVersion 8.3

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

Локальная копия

Если есть возможность поднять копию сайта локально (Local by Flywheel, Docker, обычный OpenServer) с нужной версией PHP, это самый честный способ проверки. Открываете все ключевые страницы: главную, форму, карточку товара, оформление заказа, админку. Смотрите не только на белый экран, но и на предупреждения в консоли и в логе.

Логи ошибок за последний месяц

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

Переключение версии и первые десять минут после

Сама смена версии в панели хостинга (ISPmanager, cPanel, Timeweb, Beget) занимает секунды: выбираете сайт, выбираете версию PHP из выпадающего списка, сохраняете. На PHP-FPM изменения применяются почти сразу, на некоторых конфигурациях нужно ещё принудительно перезапустить процесс через панель.

Дальше десять минут, которые решают, ляжете вы спать спокойно или будете чинить сайт ночью:

1. Открыть главную страницу в режиме инкогнито, без кэша браузера.
2. Проверить 2-3 внутренние страницы разных типов: статью, карточку услуги, форму.
3. Отправить тестовую заявку через форму обратной связи и убедиться, что письмо дошло.
4. Зайти в админку и открыть список записей, медиатеку, настройки.
5. Посмотреть свежий error_log, не появились ли новые фатальные ошибки именно с момента переключения.
6. Если сайт на WordPress, проверить сайт через wp plugin list --status=active на предмет плагинов, которые сами вывели предупреждение о несовместимости.

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

Как читать fatal error в error_log

Белый экран без единого слова на странице — это PHP fatal error, о котором на проде вслух не сообщают из соображений безопасности, но которую честно пишут в лог. Файл обычно лежит в error_log рядом с сайтом, либо путь указан в панели хостинга, либо смотрите в php.ini значение error_log.

Типичная запись выглядит так:

[28-Jul-2026 11:02:14 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function
each() in /home/user/public_html/wp-content/themes/old-theme/functions.php:214
Stack trace:
#0 /home/user/public_html/wp-includes/template.php(770): include()
#1 /home/user/public_html/wp-includes/template.php(716): load_template()
#2 {main}
  thrown in /home/user/public_html/wp-content/themes/old-theme/functions.php on line 214

Читать сверху вниз: тип ошибки, конкретная функция, файл и номер строки, где всё сломалось. Stack trace ниже показывает, что именно её вызвало, не всегда нужно, но полезно, если ошибка вылетает из глубины чужого кода, а не из вашей темы напрямую. В этом примере всё лежит на поверхности: строка 214 файла functions.php темы, функция each(), которая была удалена в PHP 8.0. Правка занимает пять минут, если знать, куда смотреть, и час, если искать наугад по всему сайту.

Откат и план Б

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

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

Чек-лист перед переходом на новую версию

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

Если после переключения сайт всё равно показывает белый экран, у меня есть отдельный разбор именно этой ситуации на WordPress: white screen of death и что с ним делать. А если проблема шире, чем один сайт, и вы вообще думаете, нужно ли сейчас лезть в обновления или лучше отложить, посмотрите статью про PHP 7.4 против PHP 8.2, там разбор именно по версиям и срокам поддержки.

Что делать, если самостоятельно разбираться некогда

Переход на новую версию PHP — разовая работа на час-два для сайта средней сложности, если делать по шагам выше. Для сайта с большим количеством кастомного кода, старыми плагинами без обновлений три-четыре года и отсутствующей документацией по составу сайта время может вырасти в несколько раз, и тут уже разумнее не рисковать боевым проектом ради экономии на подрядчике. Заодно стоит свериться с чек-листом из статьи про обновление WordPress без поломок, логика проверки там очень похожая.

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

Частые вопросы

Зачем обновлять PHP на хостинге

Ради безопасности и скорости. Старую ветку перестают чинить. Свежая на том же коде выигрывает 15-30 процентов по времени генерации страницы. Даты окончания поддержки веток опубликованы на php.net.

Как проверить совместимость CMS перед переключением

Поднять копию сайта на тестовой площадке, переключить версию там и пройти по основным сценариям: главная, каталог, форма, админка, оплата. Совместимость WordPress с версиями PHP сведена в таблице make.wordpress.org.

Что делать, если после обновления сайт упал

Вернуть прежнюю версию в панели хостинга, это занимает минуту. Потом открыть error_log, найти первую fatal error и по имени файла понять, какой плагин или тема не пережили переход.

Какая версия PHP нужна WordPress

Та, что ещё поддерживается и подходит текущей версии ядра. Актуальные требования к окружению опубликованы на wordpress.org.