Сайт не работает после обновления PHP: что делать

Почему сайт ломается после смены версии PHP

Между крупными версиями PHP разработчики языка удаляют устаревшие функции и ужесточают проверки. Код, который годами работал на PHP 7.x, на PHP 8.x может просто не запуститься. Например, функции mysql_* были удалены ещё в PHP 7.0, а create_function() и each() — в PHP 8.0. Если в старом плагине, самописном модуле или шаблоне остался такой вызов, интерпретатор остановится с фатальной ошибкой, и посетитель увидит пустую страницу.

Вторая частая причина — строгость типов. В PHP 8 арифметические операции над несовместимыми типами, например над массивом и числом, вызывают исключение TypeError, а раньше давали лишь предупреждение. В ветках 8.1 и 8.2 добавились новые предупреждения об устаревании, например о передаче null во встроенные функции и о динамических свойствах классов. Сами по себе они не всегда ломают сайт, но засоряют журнал и могут «ронять» страницы, если вывод ошибок настроен строго.

Третья причина не связана с кодом. На хостинге каждая версия PHP имеет собственный набор расширений и свой файл настроек. После переключения может оказаться, что не включены mbstring, mysqli, curl, gd или imagick, не подключён ionCube Loader или изменился memory_limit. Для сайта это выглядит как поломка, хотя «сломался» лишь набор модулей.

Первая помощь: возвращаем сайт в рабочее состояние

Не пытайтесь сразу править код. Сначала нужно вернуть работоспособность сайта, чтобы не терять заказы и обращения клиентов. Откройте панель управления хостингом, найдите раздел «PHP», «Версия PHP» или «Выбор версии PHP» и выберите ту версию, на которой сайт работал раньше. В ISPmanager, cPanel и панелях российских хостеров этот пункт находится в настройках сайта или домена.

Если сайт работает через PHP-FPM или режим CGI, изменения применяются в течение нескольких минут. После переключения очистите кеш: плагин кеширования, кеш CMS и кеш CDN, если он подключён. Затем откройте главную страницу, пару внутренних страниц, корзину или форму заявки. Когда всё работает, у вас появляется время спокойно искать причину.

Как прочитать журнал ошибок и не гадать

Журнал ошибок — главный инструмент диагностики. Обычно файл error_log лежит в корне сайта или в каталоге логов, который доступен в панели хостинга. Откройте последние записи и найдите строку с Fatal error или Uncaught. В ней всегда указаны три вещи: тип ошибки, путь к файлу и номер строки. Если путь ведёт в каталог wp-content/plugins/название-плагина, виновник найден.

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

Особенности WordPress, Битрикс и других CMS

В WordPress самая частая причина — плагин или тема, которые давно не обновлялись. Если админка недоступна, подключитесь по FTP или через файловый менеджер хостинга и переименуйте папку wp-content/plugins, например в plugins_off. Все плагины отключатся, и сайт, скорее всего, заработает. Затем возвращайте имя папки и включайте плагины по одному, пока не найдёте виновника. Тот же приём работает с темой: переименуйте её папку, и WordPress переключится на стандартную.

В 1С-Битрикс, OpenCart, Joomla и MODX перед сменой PHP нужно сверить системные требования конкретной версии CMS. Старые редакции просто не рассчитаны на PHP 8.x. В таком случае правильный путь — сначала обновить саму систему и её модули, а уже потом менять версию интерпретатора. Для самописных проектов и сайтов на устаревших фреймворках потребуется аудит кода, поэтому здесь лучше привлечь разработчика.

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

Идеальная схема проста: тестовая копия, проверка, переход. Создайте поддомен с копией сайта, включите на нём новую версию PHP и пройдите по основным сценариям: главная, каталог, карточка товара, поиск, форма заявки, оформление заказа, личный кабинет. Параллельно держите открытым журнал ошибок. Любое предупреждение уровня Deprecated — повод запланировать исправление, а любой Fatal error — блокер, который нужно закрыть до переключения.

Обновляйтесь поэтапно: например, с 7.4 на 8.1, затем на 8.2 или 8.3, а не сразу через несколько версий. Так проще понять, какое именно изменение вызвало проблему. И не откладывайте миграцию бесконечно: версии 7.4 и 8.0 больше не получают исправлений безопасности, а значит, чем дольше сайт остаётся на них, тем выше риск взлома.

После восстановления: проверьте, как сайт видят поисковики

Когда сайт снова открывается, убедитесь, что поисковые роботы не успели записать его как недоступный. В Яндекс Вебмастере посмотрите разделы диагностики и статистики обхода, а в Google Search Console — отчёты об индексировании и статистику сканирования. Ищите всплеск ответов 5xx и ошибок доступности именно в дни поломки. Если страницы возвращают нормальный код 200, дополнительных действий обычно не требуется: роботы вернутся сами.

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