Fatal Error в WordPress: как найти причину и исправить

Fatal Error в WordPress: как найти причину

Сайт работал нормально, вы обновили плагин, изменили код, переключили версию PHP или просто открыли страницу — и вместо привычного интерфейса получили сообщение о критической ошибке. Иногда WordPress вообще показывает пустую страницу, иногда перестаёт открываться только админка, Elementor с ошибкой 500, корзина WooCommerce или отдельная страница.

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

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

Поэтому искать причину Fatal Error в WordPress методом «отключим всё подряд и посмотрим» — не лучший первый шаг. Гораздо эффективнее сначала получить текст ошибки, понять его и только потом вмешиваться в работу сайта.

Что такое Fatal Error в WordPress

Fatal Error — это ошибка PHP, после которой выполнение текущего запроса продолжаться не может.

Для владельца сайта она часто скрывается за стандартным сообщением WordPress:

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

Поэтому Critical Error в интерфейсе WordPress и PHP Fatal Error в журнале могут относиться к одной и той же проблеме.

WordPress имеет встроенный механизм Recovery Mode. При обнаружении фатальной PHP-ошибки во время обычной загрузки страницы система может отправить письмо администратору сайта и предоставить специальную ссылку для входа в режим восстановления. Проблемный плагин или тема при этом могут быть временно приостановлены для административной сессии.

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

Для этого нужен журнал PHP-ошибок.

Что сделать до диагностики

Перед изменением файлов сайта желательно иметь резервную копию.

Особенно если вы собираетесь:

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

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

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

Шаг 1. Проверьте письмо администратора WordPress

Первое, что стоит сделать при сообщении «На сайте произошла критическая ошибка», — проверить почтовый адрес администратора WordPress.

В письме система может указать:

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

WordPress действительно использует этот механизм для восстановления после некоторых фатальных ошибок. Однако Recovery Mode не заменяет полноценную диагностику: отключение проблемного компонента возвращает доступ к сайту, но не объясняет, почему ошибка появилась.

Если письма нет, переходим к журналу ошибок.

Шаг 2. Включите debug.log в WordPress

Откройте файл:

wp-config.php

Он находится в корневой директории установленного WordPress.

Найдите строку:

define( 'WP_DEBUG', false );

и настройте отладку следующим образом:

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

Эти параметры выполняют три разные задачи.

WP_DEBUG включает режим отладки WordPress.

WP_DEBUG_LOG записывает ошибки в журнал.

WP_DEBUG_DISPLAY со значением false запрещает показывать технические сообщения посетителям сайта.

При стандартной конфигурации журнал появляется здесь:

wp-content/debug.log

Именно такой способ логирования описан в официальной документации WordPress. При включённом WP_DEBUG_LOG ошибки сохраняются в wp-content/debug.log, а WP_DEBUG_DISPLAY = false позволяет не выводить их непосредственно на странице.

Почему нельзя просто показывать ошибки на экране

На рабочем сайте не стоит включать отображение PHP-ошибок посетителям.

Сообщение может содержать:

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

Поэтому для production-сайта лучше записывать ошибки в лог и скрывать их вывод в браузере.

После завершения диагностики WP_DEBUG также следует снова отключить. Официальная документация WordPress не рекомендует постоянно использовать режим отладки на рабочих сайтах.

Шаг 3. Воспроизведите Fatal Error

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

Например:

• откройте проблемную страницу;
• войдите в Elementor;
• перейдите в корзину WooCommerce;
• сохраните товар;
• откройте /wp-admin/;
• повторите импорт;
• отправьте форму.

Это важно.

Если просто открыть debug.log, в нём могут находиться десятки или даже тысячи старых предупреждений, которые вообще не относятся к текущей проблеме.

Лучше запомнить точное время возникновения ошибки и затем посмотреть последние записи журнала.

Шаг 4. Найдите именно Fatal Error

Предположим, в debug.log появилась запись примерно такого вида:

PHP Fatal error: Uncaught Error: Call to undefined function example_function() in /home/site/public_html/wp-content/plugins/example-plugin/includes/class-example.php:147

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

Разберём его по частям.

PHP Fatal error

PHP сообщает, что возникла критическая ошибка, после которой выполнение запроса остановилось.

Uncaught Error

Ошибка не была перехвачена кодом приложения.

Однако слово Uncaught само по себе ещё не сообщает причину. Самая важная информация обычно идёт дальше.

Call to undefined function

PHP попытался вызвать функцию, которой в данный момент не существует.

Причины могут быть разными:

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

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

Путь к файлу

Самая интересная часть нашего примера:

/wp-content/plugins/example-plugin/

Она сразу показывает, что ошибка произошла внутри плагина example-plugin.

Номер строки

В конце сообщения находится:

:147

Это строка PHP-файла, на которой выполнение завершилось ошибкой.

Следовательно, у нас уже есть три важных факта:

компонент → файл → строка.

И вместо отключения двадцати плагинов подряд можно сразу исследовать конкретный компонент.

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

Путь из Fatal Error зачастую позволяет очень быстро сузить область поиска.

Ошибка находится в /wp-content/plugins/

Например:

/wp-content/plugins/woocommerce/
/wp-content/plugins/elementor/
/wp-content/plugins/my-custom-plugin/

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

Особенно если Fatal Error появился непосредственно после его обновления или изменения настроек.

Ошибка находится в /wp-content/themes/

Например:

/wp-content/themes/woodmart/
/wp-content/themes/my-child-theme/

Проверяем активную тему или дочернюю тему.

Если недавно редактировался functions.php, пользовательский шаблон или PHP-файл темы, начинать стоит именно с этих изменений.

Ошибка находится в /wp-content/mu-plugins/

Это Must-Use Plugin.

Такие плагины загружаются WordPress автоматически и не отключаются обычной кнопкой «Деактивировать» в разделе плагинов.

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

Ошибка находится в /wp-includes/ или /wp-admin/

Здесь нужно быть внимательнее.

Если Fatal Error произошёл в файле ядра WordPress, это не означает автоматически, что сломано само ядро.

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

Поэтому не стоит сразу редактировать файлы /wp-includes/.

Сначала необходимо посмотреть Stack Trace.

Что такое Stack Trace и зачем он нужен

После основного сообщения Fatal Error часто идёт блок:

Stack trace:
#0 ...
#1 ...
#2 ...
#3 ...

Это цепочка вызовов функций перед возникновением ошибки.

Условно:

WordPress Core
↓
WooCommerce
↓
дополнительный плагин
↓
пользовательская функция
↓
Fatal Error

Именно Stack Trace помогает отличить место, где PHP окончательно упал, от кода, который привёл его к этой ошибке.

Например, Fatal Error может указывать на функцию WooCommerce, однако выше по цепочке обнаружится сторонний плагин доставки, который передал в неё некорректное значение.

В такой ситуации бессмысленно редактировать WooCommerce. Исправлять необходимо расширение доставки.

Поэтому при профессиональной диагностике Fatal Error я смотрю не только последнюю строку сообщения, но и несколько предыдущих вызовов.

Самые частые сообщения Fatal Error

Call to undefined function

PHP не может найти вызываемую функцию.

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

Class not found

Приложение пытается использовать PHP-класс, который не был загружен.

Например:

Class "Example_Class" not found

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

Uncaught TypeError

Функция получила данные другого типа.

Например, код ожидал массив, но получил null, строку или объект.

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

Cannot redeclare

Пример:

Cannot redeclare example_function()

PHP обнаружил повторное объявление функции.

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

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

Allowed memory size exhausted

Например:

Allowed memory size of ... bytes exhausted

PHP исчерпал доступный объём памяти.

WordPress относит превышение memory limit к распространённым причинам критических ошибок.

Однако здесь есть важная деталь.

Увеличить memory limit — не всегда значит исправить причину.

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

Поэтому сначала нужно посмотреть, какой файл фигурирует рядом с ошибкой.

Maximum execution time exceeded

PHP-процесс работал дольше разрешённого сервером времени.

Причиной может быть тяжёлая операция:

• импорт;
• экспорт;
• генерация изображений;
• резервное копирование;
• API-запрос;
• сложный запрос к базе;
• зациклившийся PHP-код.

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

Parse error или syntax error

Обычно это ошибка непосредственно в PHP-коде.

Например:

• пропущена ;;
• не закрыта скобка;
• нарушены кавычки;
• повреждён массив;
• неверно вставлен PHP-сниппет.

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

Как понять, что виноват именно плагин

Предположим, журнал показывает:

/wp-content/plugins/plugin-name/

Не удаляйте плагин.

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

Если /wp-admin/ не открывается, через файловый менеджер можно временно переименовать каталог:

plugin-name

например в:

plugin-name-disabled

После этого снова откройте сайт.

Если Fatal Error исчез, связь с этим компонентом подтверждена.

Но диагностика на этом не заканчивается.

Нужно определить, почему плагин перестал работать:

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

Сам WordPress в Recovery Mode также умеет временно приостанавливать проблемные плагины или темы, чтобы администратор мог получить доступ к панели управления.

Почему отключение всех плагинов — не лучший первый метод

Совет «отключите все плагины» действительно иногда помогает.

Но на рабочем интернет-магазине это может одновременно отключить:

• оплату;
• доставку;
• формы;
• SEO-функциональность;
• интеграцию с CRM;
• кеширование;
• Elementor-дополнения.

Поэтому, если имеется доступ к журналу ошибок, сначала разумнее посмотреть конкретный путь и Stack Trace.

Массовое отключение плагинов лучше использовать как следующий диагностический этап, если лог не позволяет определить виновника.

Fatal Error после обновления WordPress или плагина

Если ошибка появилась сразу после обновления, последовательность диагностики выглядит так:

1. Не запускайте новые обновления.
2. Зафиксируйте, что обновлялось последним.
3. Проверьте Recovery Mode.
4. Получите свежую запись debug.log.
5. Определите путь к проблемному компоненту.
6. Посмотрите номер строки и Stack Trace.
7. Временно отключите именно этот компонент.
8. Проверьте совместимость версий.
9. При необходимости выполните безопасный откат.
10. После исправления протестируйте сайт повторно.

Для случая, когда сайт сломался непосредственно после обновления расширения, на MakerPress есть отдельная инструкция «Критическая ошибка WordPress после обновления плагина: как восстановить сайт». Это логичная внутренняя ссылка из этого раздела.

Что делать, если debug.log пустой

Отсутствие записей ещё не означает отсутствие PHP-ошибки.

Проверьте:

• действительно ли WP_DEBUG установлен в true;
• нет ли второго определения WP_DEBUG;
• появилась ли возможность записи в wp-content;
• существует ли серверный PHP Error Log;
• не записывает ли хостинг ошибки в отдельный журнал.

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

Кроме того, ошибка может возникать не при обычной загрузке страницы, а во время фоновой задачи, AJAX-запроса или cron-процесса. WP_DEBUG_LOG особенно полезен именно для сообщений, которые невозможно увидеть непосредственно на экране.

Когда Fatal Error появляется только на одной странице

Это хороший диагностический признак.

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

Например:

• конкретным Elementor-виджетом;
• шорткодом;
• WooCommerce-шаблоном;
• пользовательским полем;
• PHP-сниппетом;
• фильтром;
• сторонним API;
• определённым товаром;
• большим объёмом данных.

Откройте debug.log сразу после вызова именно этой страницы и сравните время ошибки.

Так область поиска уменьшается в разы.

Что не стоит делать при Fatal Error

Несколько действий нередко усложняют восстановление сайта.

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

Не редактируйте /wp-includes/ по первой строке Fatal Error.
Ошибка могла прийти туда из стороннего компонента.

Не удаляйте плагины наугад.
Сначала сохраните данные и определите виновника.

Не увеличивайте бесконечно PHP memory_limit.
Недостаток памяти может быть следствием другой проблемы.

Не оставляйте WP_DEBUG включённым постоянно.
После диагностики верните рабочую конфигурацию.

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

Правильный алгоритм поиска Fatal Error

Если сократить весь процесс до одной схемы, получается:

Fatal Error → Recovery Mode → debug.log → текст ошибки → путь → файл → строка → Stack Trace → проблемный компонент → причина → исправление → повторное тестирование.

Главная ошибка при диагностике — пытаться сразу что-нибудь «починить», не выяснив, что именно сломалось.

PHP практически всегда оставляет след.

Задача разработчика — этот след правильно прочитать.

Итог

Fatal Error в WordPress выглядит пугающе, однако само сообщение ещё не является диагнозом.

Гораздо важнее получить точный PHP Error.

В большинстве случаев журнал позволяет определить:

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

Поэтому правильная диагностика начинается не с удаления плагинов и переустановки WordPress, а с Recovery Mode, debug.log и анализа Stack Trace.

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

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

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

Где находится debug.log в WordPress?

При стандартной настройке WP_DEBUG_LOG = true WordPress записывает журнал в файл:

wp-content/debug.log

Также для WP_DEBUG_LOG можно указать собственный путь к файлу.

Чем Fatal Error отличается от Critical Error WordPress?

Fatal Error — техническая PHP-ошибка, которая останавливает выполнение запроса. Critical Error — сообщение WordPress, которое пользователь может увидеть вместо непосредственного текста фатальной ошибки.

Можно ли найти виноватый плагин по debug.log?

Да. Если путь Fatal Error содержит /wp-content/plugins/plugin-name/, этот плагин необходимо проверить первым. Однако для окончательного вывода желательно также посмотреть Stack Trace.

Что означает Allowed memory size exhausted?

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

Нужно ли оставлять WP_DEBUG включённым после исправления?

Нет. Для рабочего сайта режим отладки после завершения диагностики следует отключить. WordPress рекомендует использовать его прежде всего в средах разработки и тестирования.

Что делать, если Fatal Error указывает на wp-includes?

Не редактируйте файл ядра сразу. Сначала изучите Stack Trace: ошибка могла возникнуть из-за плагина или темы, которые передали некорректные данные в функцию WordPress.

TL;DR

При Fatal Error не отключайте всё подряд.

Сначала:

1. Проверьте письмо Recovery Mode.
2. Включите WP_DEBUG.
3. Включите WP_DEBUG_LOG.
4. Отключите WP_DEBUG_DISPLAY.
5. Повторите действие, вызывающее ошибку.
6. Откройте wp-content/debug.log.
7. Найдите последнюю запись PHP Fatal error.
8. Посмотрите путь к файлу и номер строки.
9. Изучите Stack Trace.
10. Только после этого отключайте или исправляйте проблемный компонент.

Так причина Fatal Error определяется намного быстрее и безопаснее.