Как найти баг в WordPress до того, как он найдет твою нервную систему

Баг в WordPress — существо хитрое. Он никогда не появляется во время разработки. Только в пятницу вечером, только на продакшене, только когда клиент смотрит на сайт вместе с инвестором. Васисуалий Пупкевич знает это лучше всех — он однажды три часа искал причину белого экрана, пока не выяснил, что забыл закрыть скобку. Три часа. ТРИ. ЧАСА. С включённым WP_DEBUG это заняло бы три минуты.

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

Когда нужен WP Debug

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

Включаем WP Debug: пошаговая инструкция

Скачиваем файл wp-config.php из корня сайта и открываем в текстовом редакторе. Находим строку:

/* That's all, stop editing! Happy publishing. */

Вставляем перед ней следующий блок:

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

Сохраняем и загружаем файл обратно на сервер.

Что означает каждая строка

WP_DEBUG true — главный рубильник. Включает режим отладки WordPress. Без этой строки всё остальное не работает.

WP_DEBUG_LOG true — все ошибки, предупреждения и уведомления записываются в файл wp-content/debug.log. Именно туда смотрим, когда хотим понять, что происходит.

WP_DEBUG_DISPLAY false — запрещает выводить ошибки прямо на страницах сайта. Без этой строки посетители будут видеть PHP-ошибки в полный экран — зрелище душеразрывающее и для SEO вредное. Пусть ошибки идут в лог, а не на витрину.

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

Где смотреть лог

После того как debug включён и сайт поработал, лог находится по адресу:

/wp-content/debug.log

Скачиваем через FTP/SFTP и открываем в любом текстовом редакторе. Ищем строки с PHP Fatal error, PHP Warning и PHP Notice — они и есть виновники торжества.

Васисуалий однажды открыл debug.log и обнаружил там 40 000 строк предупреждений от плагина, который он поставил «просто попробовать» два года назад и забыл удалить. Мораль: лог надо чистить регулярно.

Чистим лог через WP-CLI

Накопившийся лог — враг диагностики. Если в файле сотни тысяч старых записей, найти свежую ошибку в этом потоке сознания крайне сложно. Перед каждой диагностической сессией чистим лог командой WP-CLI:

wp eval 'file_put_contents(WP_CONTENT_DIR . "/debug.log", "");'

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

Подробнее о том, что умеет WP-CLI и как его установить — в нашем посте → Как запустить WordPress в режиме терминатора.

Выключаем Debug после работы

WP Debug на продакшен-сайте — инструмент временный. Как только разобрались с проблемой, возвращаем WP_DEBUG в false или удаляем блок целиком:

define('WP_DEBUG', false);

Держать debug включённым постоянно — значит писать все внутренности сайта в лог-файл круглосуточно. Диск это не любит, безопасность тоже.