После обновления WooCommerce вместо витрины — серая плашка «На сайте возникла критическая ошибка». Не знаете, с чего начать? См. алгоритм по симптомам. В практике письмо администратору с именем плагина приходит не всегда: на Beget и Timeweb mail() часто молчит. Разберём, где взять расшифровку fatal и как зайти в Recovery Mode без паники.
Что показывает WordPress 5.2+
Начиная с версии 5.2 WordPress перехватывает fatal PHP-ошибки и показывает «дружелюбное» сообщение:
«There has been a critical error on this website. Please check your site admin email inbox for instructions. Learn more about troubleshooting WordPress.»
В русской локализации — «На сайте возникла критическая ошибка. Подробности — на электронной почте администратора сайта.» Параллельно WordPress отправляет письмо администратору с темой [Имя сайта] Your Site is Experiencing a Technical Issue и ссылкой для входа в Recovery Mode.
Куда смотреть в первую очередь
1. Письмо администратору
Откройте почту того адреса, который указан в Настройках → Общие как Email администратора. Письмо называется примерно так: [ваш сайт] Your Site is Experiencing a Technical Issue. Внутри — расшифровка fatal-ошибки, имя плагина или темы, файл и строка кода. Это самое полезное, что можно получить, не лазая по серверу.
Письма не пришло? Значит, либо хостинг не отправляет почту по mail() (часто на shared), либо письмо в спаме, либо адрес в Настройках уже не работает. Тогда — следующий пункт.
2. Recovery Mode (вручную)
В письме есть ссылка вида https://ваш-сайт.ru/wp-login.php?action=enter_recovery_mode&rm_token=...&rm_key=.... Если письмо потеряно, такую ссылку можно сгенерировать вручную через PHP-консоль, но проще — следующий шаг.
3. debug.log
Открываете wp-config.php по FTP, добавляете три строки:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);Обновляете страницу. В wp-content/debug.log появляется конкретная ошибка с трассировкой. По имени папки в стеке вызовов сразу понятно, какой плагин виноват.
Типовые fatal-ошибки и что они означают
Cannot redeclare function ...
Два плагина определяют функцию с одним именем. Часто бывает, когда внутри плагина «зашита» библиотека (ACF, FacetWP, какая-нибудь Geo IP), и параллельно её же поставили отдельным плагином. Решение: оставить одну копию, остальные деактивировать.
Class ... not found
Плагин ссылается на класс из другого плагина, который не активен или удалён. Часто — после «массовой деактивации» проблемного плагина не учли, что от него зависят другие. Решение: либо включить обратно зависимость, либо удалить плагин, который её требует.
Allowed memory size exhausted
Не хватает PHP memory_limit. Решается так же, как при белом экране: в wp-config.php добавить define('WP_MEMORY_LIMIT', '256M');, а если не помогло — поднять лимит на уровне хостинга. Подробности — в статье про WSOD.
Maximum execution time of 30 seconds exceeded
Скрипт работает дольше дефолтных 30 секунд. Чаще всего — массовый импорт товаров, генерация большого XML, обновление БД через миграцию. В .htaccess:
php_value max_execution_time 300Uncaught Error: Call to undefined function ...
Плагин использует функцию, которой нет в этой версии WordPress или PHP. Обычно после понижения версии PHP хостером или после обновления плагина. Решение: либо откатить плагин на старую версию, либо обновить PHP / WordPress до нужной.
Сценарий «не пускает в админку, recovery-ссылки нет»
Если письма не приходят, в админку не пускает, recovery-режим недоступен — действуем так (все способы — в гайде по отключению плагинов без админки):
- Открываете
debug.logи определяете виновный плагин / тему по пути файла в стеке. - Подключаетесь по FTP / SSH.
- Переименовываете папку плагина:
wp-content/plugins/имя-плагина→имя-плагина_OFF. Это «деактивирует» плагин без участия БД. - Открываете сайт — он должен ожить. Заходите в админку.
- Через админку чисто удаляете проблемный плагин или ставите рабочую версию.
- Переименовываете папку обратно (она пустая — это нормально, она нужна, чтобы WordPress правильно очистил настройки плагина).
Как починить «по-настоящему»
Recovery Mode позволяет деактивировать плагин и снова попасть в админку, но это убирает только проявление, а не причину. Чтобы critical error не повторилась:
- Найдите истинную причину по
debug.logи письму администратору. - Если виноват плагин — откатите его на предыдущую версию или обновите до новой, в которой баг исправлен. Если плагинов много и непонятно, с чего начать — см. аудит списка расширений.
- Если виновата тема — проверьте, что её версия совместима с PHP и WordPress на сервере.
- Настройте регулярные бэкапы (UpdraftPlus, BackWPup) в облако — чтобы в следующий раз решение занимало 5 минут.
Когда позвать спеца
Если в debug.log непонятный стек, ошибка в файле ядра WordPress (но это почти всегда «эхо» от другого плагина) или повторяется через час после починки — пишите. Восстановим за 1–3 часа в рабочее время.
