WebFixer24 Обсудить задачу

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

Разбираем, как найти причину, проверить плагины и тему, посмотреть логи и безопасно восстановить работу сайта.

Обновлено: Время чтения: около 8 минут

Сообщение «На сайте возникла критическая ошибка» означает, что WordPress столкнулся с фатальной ошибкой и не смог нормально выполнить PHP-код.

Причина может находиться в плагине, теме, пользовательском коде, несовместимости версий PHP или в изменениях, которые недавно произошли на сайте.

Главное в такой ситуации — не начинать хаотично удалять файлы и переустанавливать WordPress. Сначала нужно понять, на каком участке возникает ошибка.

Сначала вспомните последние изменения

Если критическая ошибка появилась внезапно, вспомните, что происходило с сайтом непосредственно перед этим:

  • обновлялся WordPress;
  • обновлялся или устанавливался плагин;
  • менялась тема;
  • редактировался functions.php или другой PHP-код;
  • менялась версия PHP на хостинге;
  • переносился сайт;
  • устанавливался новый модуль или интеграция.

Это не доказывает причину, но значительно сужает область поиска.

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

↑ К оглавлению

Проверьте Recovery Mode

Начиная с WordPress 5.2 система умеет перехватывать часть фатальных ошибок.

Если ошибка связана с плагином или темой, WordPress может отправить письмо на административный email сайта. В нём обычно находится информация о проблемном компоненте и специальная ссылка для входа в режим восстановления — Recovery Mode.

В этом режиме проблемный плагин или тема временно приостанавливается для вашей административной сессии. Это позволяет войти в панель управления и посмотреть, какой компонент вызвал сбой.

Проверьте:

  • основной почтовый ящик администратора;
  • папку «Спам»;
  • адрес администратора, указанный в настройках WordPress.

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

↑ К оглавлению

Посмотрите PHP-ошибку и debug.log

Фраза «На сайте возникла критическая ошибка» сама по себе почти ничего не говорит о причине.

Намного полезнее увидеть конкретную PHP-ошибку и файл, в котором она произошла.

Для диагностики WordPress можно временно включить логирование в wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

После повторного открытия проблемной страницы сообщения обычно записываются в:

/wp-content/debug.log

Нас прежде всего интересуют записи типа:

PHP Fatal error

а также путь к файлу, имя функции и номер строки.

Например, если ошибка указывает на файл:

/wp-content/plugins/example-plugin/...

в первую очередь нужно проверять этот плагин.

Если путь ведёт в активную тему:

/wp-content/themes/example-theme/...

проверяется тема или внесённые в неё изменения.

Не оставляйте режим отладки включённым без необходимости на рабочем сайте. После диагностики его следует отключить.

↑ К оглавлению

Проверьте плагины

Плагины — одна из возможных причин фатальной ошибки WordPress.

Если из Recovery Mode или журнала ошибок уже понятно, какой именно плагин вызывает сбой, безопаснее сначала отключить конкретно его.

Если административная панель недоступна, это можно сделать через файловый менеджер хостинга или SFTP.

Например:

/wp-content/plugins/example-plugin/

временно переименовывается в:

/wp-content/plugins/example-plugin-disabled/

WordPress перестанет загружать этот плагин.

Если после этого сайт заработал, причина локализована. Но это ещё не означает, что проблему нужно считать окончательно решённой.

Дальше стоит выяснить:

  • совместим ли плагин с текущей версией WordPress;
  • совместим ли он с используемой версией PHP;
  • не конфликтует ли он с другим плагином;
  • не повреждены ли его файлы;
  • не появились ли ошибки после обновления самого плагина.

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

↑ К оглавлению

Проблемы после обновления

Обновление WordPress, темы или плагина иногда лишь проявляет уже существовавшую несовместимость.

Поэтому схема:
«После обновления сломалось → откатить всё назад»
не всегда является лучшим решением.

Сначала желательно определить конкретную ошибку и компонент, который её вызывает.

Если сайт перестал работать именно после обновления, отдельно смотрите наше руководство по восстановлению WordPress после обновления.

↑ К оглавлению

Проверьте тему и версию PHP

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

Особенно это актуально, если:

  • недавно обновлялась тема;
  • редактировался functions.php;
  • добавлялись собственные PHP-фрагменты;
  • использовалась дочерняя тема;
  • менялась версия PHP.

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

Слепая замена темы на рабочем сайте может изменить внешний вид и функциональность, поэтому перед такими действиями лучше иметь резервную копию.

Плагин или тема могут нормально работать на одной версии PHP и выдавать фатальную ошибку после перехода на другую.

Это особенно важно, если хостинг недавно автоматически изменил версию PHP.

Нужно проверить:

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

Простое переключение версии PHP наугад — плохая диагностика. Лучше сначала посмотреть ошибку, а уже затем принимать решение.

↑ К оглавлению

Если недоступна и админка

Критическая ошибка может блокировать и публичную часть сайта, и административную панель.

Если /wp-admin/ тоже недоступен, остаются серверные способы диагностики:

  1. проверить письмо Recovery Mode;
  2. посмотреть debug.log;
  3. посмотреть PHP/error log в панели хостинга;
  4. через файловый менеджер отключить конкретный проблемный плагин;
  5. проверить недавние изменения файлов;
  6. при необходимости работать на копии сайта или staging.

Не нужно для начала удалять WordPress, очищать базу данных или переустанавливать сайт.

В большинстве случаев фатальная ошибка имеет конкретную причину, которую можно увидеть в логах.

↑ К оглавлению

Резервная копия и безопасный порядок

Резервная копия может быстро вернуть сайт в рабочее состояние, если точно известно, что на момент её создания всё работало.

Но восстановление backup не отвечает на вопрос, почему появилась ошибка.

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

Поэтому хороший порядок обычно такой:

восстановить доступность сайта, если это срочно → определить причину → устранить её → проверить результат.

Перед любыми существенными изменениями текущую копию сайта и базы данных тоже желательно сохранить.

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

Например, если:

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

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

↑ К оглавлению

Порядок действий

Если WordPress показывает критическую ошибку:

  1. Не удаляйте сайт и базу данных.
  2. Вспомните последние изменения.
  3. Проверьте письмо от WordPress с Recovery Mode.
  4. Сделайте резервную копию, если её ещё нет.
  5. Получите конкретную ошибку из логов.
  6. Определите файл, плагин или тему, где возникает сбой.
  7. Отключайте или исправляйте именно найденный компонент.
  8. Проверьте совместимость WordPress, плагинов, темы и PHP.
  9. После исправления протестируйте публичную часть сайта и административную панель.
  10. Отключите диагностический режим.
↑ К оглавлению

Частые вопросы

Что означает критическая ошибка WordPress?

Это означает, что во время выполнения PHP-кода произошла фатальная ошибка, из-за которой WordPress не смог нормально сформировать страницу.

Может ли причиной быть плагин?

Да. Причиной может быть сам плагин, его обновление, конфликт с другим компонентом или несовместимость с используемой версией PHP. Конкретную причину лучше определять по журналу ошибок.

Что делать, если ошибка появилась после обновления?

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

Как отключить плагин, если не открывается админка?

Проверьте письмо Recovery Mode и серверные логи. Если известен проблемный плагин, его можно временно отключить через файловый менеджер или SFTP, не заходя в панель WordPress.

Можно ли восстановить сайт из резервной копии?

Можно, если есть заведомо рабочая копия. Но после восстановления желательно выяснить причину сбоя, иначе проблема может повториться.

Когда лучше остановить самостоятельные эксперименты?

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

↑ К оглавлению

Нужна помощь с WordPress?

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

Оформить обращение можно любым удобным способом:

Здесь, без регистрации Через KWORK
↑ К оглавлению