Ошибки после обновления PHP: как найти и исправить

Почему обновление PHP вообще способно сломать сайт

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

Сайт же часто живёт годами: тема написана подрядчиком в 2016 году, плагин не обновлялся с 2019-го, а в корне лежит скрипт, который «просто работает». Пока версия PHP не менялась, всё это не вызывало вопросов. После обновления накопленный «технический долг» проявляется одновременно.

Отдельная причина — окружение. Новая версия PHP на сервере почти всегда работает со своим набором расширений и своим файлом php.ini. Если на старой версии был включён модуль mbstring или ionCube Loader, на новой его может не быть, пока вы не включите его вручную.

Что именно меняется между версиями

Все изменения можно разделить на три группы. Первая — удалённые возможности: функция или расширение исчезает совсем, и вызов приводит к ошибке Call to undefined function. Вторая — изменение поведения: код продолжает выполняться, но работает иначе, например сравнение строки с числом в PHP 8 даёт другой результат. Третья — устаревшие конструкции (Deprecated): пока всё работает, но в логе появляются предупреждения, а в одной из следующих версий конструкцию уберут.

Особенно болезненным считается переход с ветки 7.x на 8.x. Именно в PHP 8.0 многие предупреждения стали исключениями TypeError и ValueError, а уведомления о неопределённых переменных и ключах массива превратились в предупреждения Warning. Ниже — краткая хронология, которая поможет понять, в какой версии «сломалось» то, что вы видите в логе.

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

Сообщения об ошибках после обновления разнообразны, но укладываются в несколько типичных сценариев. Одни видны сразу: страница пустая или браузер показывает «500 Internal Server Error». Другие скрыты: на главной всё в порядке, а не работает корзина, форма обратной связи или личный кабинет.

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

Начните с логов, а не с догадок

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

Где искать записи: файл error_log в корне сайта или рядом с проблемным скриптом, журнал PHP-FPM, error.log веб-сервера (Nginx или Apache), раздел «Логи» в панели хостинга. Если вывод в лог выключен, включите его в php.ini или в настройках сайта: `log_errors = On`, `error_reporting = E_ALL`, `display_errors = Off`. Последний параметр важен: показывать ошибки посетителям на рабочем сайте нельзя.

В WordPress добавьте в wp-config.php константы `WP_DEBUG` и `WP_DEBUG_LOG`, и записи появятся в файле wp-content/debug.log. В 1С-Битриксе параметры вывода ошибок задаются в настройках ядра (файл .settings.php, секция exception_handling).

Типовые правки в коде

Большинство проблем в собственном коде повторяется от проекта к проекту. Это обращения к неопределённым переменным и ключам массива, передача null в строковые функции, вызов count() от значения, которое не является массивом, остатки функций из ветки 5.x и старый синтаксис доступа к символам строки через фигурные скобки.

Отдельно стоит упомянуть изменение сравнения. До PHP 8 выражение `0 == 'abc'` считалось истинным, а теперь даёт false. Если в коде есть проверки вида «если значение равно нулю» над строковыми данными, логика может измениться без единой ошибки в логе. Такие случаи находятся только тестами и вниманием к условиям.

Ниже — пять самых частых правок в формате «было / стало».

Плагины, темы, Composer и расширения

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

Для проектов на Composer важно запускать установку зависимостей именно на целевой версии PHP. Сообщение вида «Your Composer dependencies require a PHP version >= 8.1» означает, что файл проверки платформы в vendor фиксирует требования пакетов. Обновите зависимости командой `composer update` на тестовой копии и убедитесь, что все пакеты поддерживают нужную версию.

Отдельно проверьте закодированные продукты. Скрипты, защищённые ionCube или Zend Guard, привязаны к конкретной версии загрузчика. Если для новой версии PHP нужного загрузчика нет, продукт придётся обновить у вендора.

Тестовая среда и план отката

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

План отката — это одно предложение, записанное заранее: «если за 30 минут не нашли причину, возвращаем версию X и работаем на копии». Он снимает панику и защищает от попыток чинить сайт под давлением, когда заказы не поступают.

Перед самим обновлением удобно пройтись по короткому чек-листу.