Критическая ошибка WordPress после обновления PHP 8.3: разбор восстановления и чек-лист

Если после обновления PHP WordPress пишет «На сайте возникла критическая ошибка», самый быстрый путь назад такой: открыть лог ошибок, найти плагин, названный в фатальной ошибке, отключить его переименованием папки через SFTP или SSH, а потом обновить остальное до версий, которые поддерживают вашу версию PHP. Ровно так и прошёл этот случай, ниже — по шагам и с командами.

Что случилось

Хостинг перевёл сайт на PHP 8.3. После этого не работали ни фронтенд, ни админка — зайти через панель управления было невозможно.

Ответ нашёлся в логе сервера почти сразу: фатальная ошибка в плагине Really Simple SSL Pro при проверке лицензии. Вокруг неё — сотни Deprecated-предупреждений от других модулей. По объёму они пугали, но сайт уронили не они.

А когда доступ вернулся, вылезла вторая проблема: пропали таблицы Yoast SEO Premium, и генерация sitemap остановилась полностью. То есть сайт снова открывался, но тихо терял SEO-обвязку. Такое обычно замечают, только когда проседает трафик.

Почему обновление PHP ломает WordPress

Само ядро WordPress новые версии PHP переносит нормально. Ломаются почти всегда плагины и темы, написанные под старый PHP и с тех пор не обновлявшиеся. Между PHP 7.4 и 8.3 по старому коду сильнее всего бьют несколько изменений:

• функции, которых больше нет, — create_function() и each() удалены в PHP 8.0, и код падает с фатальной ошибкой в момент вызова;
• более строгая работа с типами: то, что PHP 7 молча приводил, теперь выбрасывает TypeError;
• передача null во встроенные функции, ожидающие строку, — deprecated с 8.1, динамические свойства у объектов — deprecated с 8.2.

Разница между двумя видами сообщений важна. Fatal error обрывает запрос — это и есть ваша авария. Deprecated — предупреждение на будущее: шумное, исправлять стоит, но само по себе сайт не роняет. Здесь одна фатальная ошибка пришла вместе с сотнями deprecated, и главное было — не утонуть в предупреждениях.

Шаг 1. Найти настоящую ошибку

За страницей «критическая ошибка» WordPress прячет подробности, поэтому нужен лог. Где смотреть:

1. Письмо режима восстановления. С версии 5.2 при фатальной ошибке WordPress отправляет на почту администратора письмо с названием сломанного плагина и специальной ссылкой: она открывает админку с приостановленным плагином. Проверьте почту и спам первым делом — это экономит кучу времени.
2. Лог ошибок PHP на сервере. В большинстве хостинговых панелей он есть, либо лежит рядом с файлами сайта.
3. Собственный debug-лог WordPress. Добавьте в wp-config.php выше строки «Это всё, дальше не редактируем»:

// TODO: убрать после отладки — debug.log по умолчанию доступен из браузера
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // пишет в wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // не показывать ошибки посетителям
@ini_set( 'display_errors', 0 );

Обновите сломанную страницу и откройте wp-content/debug.log. Ищите первую строку, начинающуюся с PHP Fatal error: в ней указан файл, а по пути к файлу понятно, какому плагину или теме он принадлежит.

Шаг 2. Вернуть доступ без админки

Когда не открывается сама админка, виновника отключают снаружи. Я переименовал каталог сломанного плагина через файловую систему:

# TODO: подставьте имя папки из вашей фатальной ошибки
cd wp-content/plugins
mv really-simple-ssl-pro really-simple-ssl-pro.off

WordPress перестаёт видеть плагин, деактивирует его, и сайт начинает загружаться. Если на сервере есть WP-CLI, то же самое делается аккуратнее:

# --skip-plugins — чтобы команда не загружала сломанный плагин
wp plugin deactivate really-simple-ssl-pro --skip-plugins --skip-themes

Если ошибка указывает на тему, переключитесь на стандартную тем же способом: wp theme activate twentytwentyfive --skip-plugins --skip-themes.

Отдельная оговорка про SSL-плагины: они часто отвечают за редирект с HTTP на HTTPS. После отключения проверьте, что редирект остался и не появились предупреждения о смешанном контенте. Если появились — редирект в любом случае надёжнее держать на уровне сервера.

Шаг 3. Убрать предупреждения с публичных страниц

Сотни deprecated прямо на сайте выглядят для посетителей как поломка и светят пути к файлам. Пока плагины не обновлены, я отключил вывод в конфиге ядра:

define( 'WP_DEBUG', false );
ini_set( 'display_errors', 0 );

Это прячет симптом, а не лечит. Пластырь на те часы, что проходят между «сайт открывается» и «всё обновлено».

Шаг 4. Обновить ядро и все расширения

Дальше обновил ядро WordPress и все плагины до версий, совместимых с PHP 8.3. Два практических момента:

• Премиум-плагины (здесь это были Yoast SEO Premium и Really Simple SSL Pro) обновляются только при активной лицензии. Истекла лицензия — значит, на новом PHP крутится старый код, и именно так подобные аварии и начинаются.
• Перед обновлением посмотрите строку «Требуется версия PHP» на странице плагина. Если плагин не обновлялся годами, велик шанс, что PHP 8.3 он не поддержит никогда — и заменить его дешевле, чем латать.

Проверить код до переключения PHP можно набором правил PHPCompatibilityWP для PHP_CodeSniffer. Это статический анализ, он кое-что пропускает, но удалённые функции и явные проблемы синтаксиса ловит:

# TODO: укажите путь к своему wp-content
phpcs -p wp-content/plugins wp-content/themes \
  --standard=PHPCompatibilityWP --runtime-set testVersion 8.3- --extensions=php

Шаг 5. Пропавшие таблицы Yoast SEO

Когда сайт поднялся, ошибки базы данных оказались в том, что Yoast SEO не находил свою таблицу indexable. Запрос, на котором он спотыкался:

SELECT * FROM yoast_wp_seo_models_indexable WHERE object_id = '1' AND object_type = 'user' LIMIT 1

Решение оказалось простым, когда стало понятно, на что я смотрю: деактивация и повторная активация Yoast запустили его автоматическую миграцию. Служебные таблицы пересоздались, а встроенный инструмент оптимизации SEO-данных заново их заполнил. После этого sitemap снова начал генерироваться.

Если после любой аварии или неудачного обновления видите ошибки Yoast — сначала попробуйте это. Восстановление таблиц из бэкапа — запасной вариант, а не первый ход.

Результат

• Uptime восстановлен до 99.99%
• Ответ сервера +25% — уже за счёт самого перехода на PHP 8.3
• Ошибки БД устранены на 100%
• Потеря органического трафика остановилась, как только вернулся sitemap

Ирония в том, что обновление PHP, которое уронило сайт, после наведения порядка сделало его заметно быстрее.

Как обновлять PHP на WordPress без аварии

Что советую теперь, чтобы следующее обновление прошло скучно:

1. Сделать полный бэкап — файлы и базу — и проверить, что он действительно разворачивается.
2. Скопировать сайт на тестовую копию и переключить PHP сначала там.
3. Обновить ядро, плагины и тему на тестовой копии, продлить лицензии премиум-плагинов заранее.
4. Прокликать ключевые страницы, корзину или формы с включённым WP_DEBUG_LOG и прочитать лог.
5. Переключить PHP на рабочем сайте в спокойный час. В большинстве панелей хостинга версию можно вернуть за минуту, так что план отката — один выпадающий список.
6. Сутки поглядывать в лог: часть кода выполняется только по крону или на отдельных страницах.

FAQ

Что делать, если после обновления PHP на сайте WordPress возникла критическая ошибка? Найти фатальную ошибку в письме режима восстановления или в wp-content/debug.log, отключить названный в ней плагин переименованием папки через SFTP или SSH, затем обновить его или заменить на совместимый с вашей версией PHP.

Как зайти в админку WordPress, если сайт показывает критическую ошибку? По ссылке из письма режима восстановления — она открывает админку с приостановленным плагином. Если письма нет, переименуйте папку плагина в wp-content/plugins, и админка обычно возвращается.

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

Как откатить версию PHP на WordPress? В большинстве хостинговых панелей версия PHP меняется для каждого сайта в выпадающем списке и применяется в течение минуты. Откатитесь, а совместимость исправляйте на тестовой копии.

Почему после обновления PHP пропали таблицы Yoast SEO? В этом случае таблицы indexable отсутствовали после сбоя. Деактивация и повторная активация Yoast запустили миграцию и пересоздали их, а встроенный инструмент оптимизации заполнил данные заново.