Как включить и настроить режим отладки в WordPress для разработки

Автор: Лев Васильев | Опубликовано: 24.10.2026

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

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

Что делает debug-режим в WordPress

WordPress сам по себе не исправляет ошибки, а только может сообщать о них через встроенные константы в файле wp-config.php. Когда включён WP_DEBUG, система начинает показывать уведомления, предупреждения и ошибки PHP, которые связаны с темой, плагинами или собственным кодом.

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

Как включить отладку в wp-config.php

Основная настройка делается в корне сайта, в файле wp-config.php. Его нужно редактировать аккуратно: одна лишняя запятая или символ могут сломать загрузку сайта. Перед изменением сделайте резервную копию файла, а если сайт уже работает нестабильно — лучше сохранить и копию базы данных.

Найдите строку с комментарием /* That's all, stop editing! Happy publishing. */. Обычно нужные константы добавляют выше неё. Для разработки минимальный набор выглядит так:

define( 'WP_DEBUG', true );

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

Как включить логирование ошибок без показа посетителям

Чтобы собирать ошибки в файл и не светить их пользователям, добавьте ещё несколько констант. Этот вариант подходит для реального сайта, где нужно диагностировать проблему без лишнего шума в браузере:

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

Что здесь происходит:

WP_DEBUG включает режим отладки;
WP_DEBUG_LOG записывает ошибки в файл wp-content/debug.log;
WP_DEBUG_DISPLAY отключает вывод ошибок на страницу;
@ini_set( 'display_errors', 0 ) дополнительно просит PHP не показывать ошибки в браузере, если хостинг это позволяет.

Такой набор обычно и нужен для безопасной диагностики. Если хостинг ограничивает изменение PHP-настроек, строка с ini_set может не дать эффекта, но остальные константы WordPress всё равно работают.

Где искать лог и как понять, что всё работает

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

Проверить результат можно так:

на странице не должно появляться служебных сообщений PHP;
в каталоге wp-content должен появиться файл debug.log;
внутри файла будут строки с датой, типом ошибки и путём к файлу, где она возникла.

Если файл не создаётся, проверьте права на запись в wp-content. На некоторых хостингах лог может не писаться из-за ограничений прав или особенностей конфигурации PHP. В таком случае смотрите системный error log хостинга — иногда ошибки WordPress и PHP попадают именно туда.

Как не оставить debug включённым на боевом сайте

После того как проблема найдена, режим отладки лучше выключить. Постоянно включённый debug на рабочем сайте — это лишняя нагрузка и риск утечки технической информации. Особенно опасно оставлять включённым вывод ошибок на экран.

Для обычной работы верните настройки к такому виду:

define( 'WP_DEBUG', false );

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

Когда одного debug.log недостаточно

Иногда ошибка не попадает в лог WordPress, потому что проблема возникает раньше загрузки ядра, на уровне веб-сервера, PHP-FPM или расширения PHP. В таком случае debug.log будет пустым или в нём окажется только часть картины. Тогда нужно смотреть:

error log веб-сервера;
лог PHP;
логи хостинга в панели управления;
конфликт плагинов или темы, если ошибка проявляется только после их активации.

Если сайт перестал открываться после правки wp-config.php, сначала проверьте сам файл на синтаксическую ошибку. WordPress очень чувствителен к лишним пробелам, незакрытым кавычкам и случайно вставленному символу. В такой ситуации проще всего вернуть резервную копию файла и вносить изменения заново.

Практичный порядок диагностики

Если нужно быстро найти источник ошибки, удобнее идти по короткому сценарию:

Сделать копию wp-config.php.
Включить WP_DEBUG, WP_DEBUG_LOG и отключить WP_DEBUG_DISPLAY.
Повторить действие, которое вызывает сбой.
Открыть wp-content/debug.log и найти свежую запись.
Проверить файл, плагин или тему, на которые указывает путь в сообщении.
После исправления вернуть WP_DEBUG в false.

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

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