Решение проблем 9 мин чтения

На сайте возникла критическая ошибка WordPress: как исправить

Что значит «На сайте возникла критическая ошибка» в WordPress и как её исправить: режим восстановления, debug.log, отключение плагинов и темы, память и версия PHP.

Сообщение «На сайте возникла критическая ошибка» появляется, когда PHP наткнулся на фатальную ошибку и не смог продолжить работу. Такую страницу WordPress показывает вместо привычного белого экрана смерти. Хорошая новость: причина почти всегда находится в одном плагине, теме или настройках сервера, и исправить её можно самостоятельно.

Что означает эта ошибка

Начиная с WordPress 5.2 встроена защита от фатальных ошибок. Когда плагин или тема вызывает Fatal error, WordPress перехватывает его, показывает нейтральное сообщение и отправляет письмо администратору с подробностями. Фактически вы видите внешнее проявление PHP-ошибки, например:

PHP Fatal error: Uncaught Error: Call to undefined function ...
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
PHP Parse error: syntax error, unexpected ...

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

Шаг 1. Письмо с режимом восстановления

WordPress отправляет письмо на адрес администратора сайта (он указан в «Настройки → Общие» как «Адрес электронной почты администрирования»). Тема письма содержит слова о проблеме на сайте. В нём вы найдёте:

  • название плагина или темы, вызвавшего ошибку;
  • текст ошибки и путь к файлу со строкой;
  • ссылку для входа в режим восстановления (Recovery Mode).

Перейдите по ссылке и авторизуйтесь. В режиме восстановления вы попадёте в админку, а проблемный плагин или тема будут приостановлены именно для вас. Откройте «Плагины» или «Внешний вид → Темы», деактивируйте или удалите виновника.

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

Шаг 2. Включите журнал ошибок

Откройте wp-config.php в корне сайта через FTP или файловый менеджер хостинга и найдите строку /* That's all, stop editing! */. Прямо перед ней добавьте:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Эти константы включают режим отладки, запись ошибок в файл и скрывают вывод ошибок на экран, чтобы посетители не видели технических деталей. Если в файле уже есть строка define( 'WP_DEBUG', false );, не дублируйте её, а замените значение.

Затем повторите действие, которое приводит к ошибке (откройте страницу или админку). Журнал появится в файле:

wp-content/debug.log

Откройте его и посмотрите последние строки. В записи будет путь к файлу, например wp-content/plugins/название-плагина/файл.php on line 123. По пути сразу видно, кто виноват: плагин, тема или ядро.

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

Шаг 3. Отключите плагины вручную

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

  1. Подключитесь по FTP или откройте файловый менеджер.
  2. Перейдите в wp-content/.
  3. Переименуйте папку plugins в plugins_off.

WordPress не найдёт плагины и сам деактивирует их. Проверьте сайт. Если ошибка исчезла, причина в плагине:

  1. Верните папке имя plugins.
  2. Откройте «Плагины», они будут отключены. Включайте их по одному, проверяя сайт после каждого.
  3. Когда ошибка вернётся, вы нашли виновника.

Чтобы отключить только один подозрительный плагин, переименуйте не всю папку, а только его каталог внутри plugins/.

Шаг 4. Смените тему

Если ошибка в логе указывает на wp-content/themes/, переименуйте папку активной темы, например mytheme в mytheme-off. WordPress переключится на одну из стандартных тем (Twenty Twenty-Four и подобные), если она установлена. Если стандартных тем нет, загрузите любую из них в wp-content/themes/.

Недавно правили functions.php? Восстановите прежнюю версию файла из резервной копии: одной лишней запятой или скобки достаточно для критической ошибки.

Частые причины

Обновление плагина или темы

Самая распространённая причина: после обновления новая версия конфликтует с другим плагином, темой или версией PHP. Решение: деактивировать плагин, откатить версию (для этого поможет плагин управления версиями или резервная копия) и дождаться исправления от разработчика.

Несовместимая версия PHP

Старый плагин может не работать на новом PHP, а новый плагин требует свежий PHP, которого нет на хостинге. В логе это проявляется ошибками про неопределённые функции, устаревшие синтаксис и классы. Проверьте в описании плагина строки «Требуется PHP» и «Протестировано с WordPress». Как менять версию, рассказано в статье «Как обновить PHP на WordPress».

Нехватка памяти

Ошибка Allowed memory size ... exhausted означает, что скрипт выбрал лимит памяти. Увеличить его можно в wp-config.php, перед строкой «That’s all, stop editing!»:

define( 'WP_MEMORY_LIMIT', '256M' );

Если лимит самого хостинга (memory_limit в настройках PHP) ниже, значение из WordPress не поможет: тогда лимит нужно поднять в панели хостинга или через обращение в поддержку. Если ошибка возвращается при любом лимите, ищите «прожорливый» плагин или бесконечный цикл.

Повреждённые файлы

Незавершённое обновление или обрыв загрузки по FTP оставляют битые файлы. Загрузите свежую копию плагина или темы поверх старой, а для ядра переустановите WordPress через «Консоль → Обновления → Переустановить» либо замените папки wp-admin и wp-includes файлами из архива той же версии.

Что делать после исправления

  1. Выключите режим отладки: удалите три строки отладки из wp-config.php или поставьте WP_DEBUG в false. Файл debug.log может содержать пути и данные, поэтому удалите его.
  2. Обновите WordPress, тему и плагины, но не всё сразу, а по очереди, проверяя сайт.
  3. Настройте резервное копирование. Подходящие решения есть в каталоге плагинов для бэкапа.
  4. Проверьте обновления на копии сайта (стейджинге), прежде чем применять их на рабочем сайте.

Если не получилось

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

Оставить заявку

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