Если сайт начал показывать белый экран, предупреждения PHP или странно ведёт себя тема или плагин, первым делом имеет смысл включить отладку WordPress так, чтобы ошибки записывались в лог, но не выводились посетителям. Это безопаснее для рабочего сайта: вы получаете данные для диагностики, а пользователи не видят пути к файлам, фрагменты кода и внутренние сообщения сервера.
В WordPress за это отвечают несколько констант в файле wp-config.php. Самая важная из них — WP_DEBUG. Она включает режим отладки CMS, но сама по себе не гарантирует запись в файл и не должна автоматически означать публичный вывод ошибок.
Что именно нужно включить
Для типичного сценария диагностики на рабочем сайте нужны три вещи:
WP_DEBUG— включает отладочный режим WordPress;WP_DEBUG_LOG— записывает сообщения в файл журнала;WP_DEBUG_DISPLAY— управляет выводом ошибок на экран.
Если задача — собрать ошибки и не показывать их посетителям, обычно используют связку WP_DEBUG = true, WP_DEBUG_LOG = true, WP_DEBUG_DISPLAY = false. На практике это самый полезный вариант для живого сайта, когда проблема уже проявилась и нужно понять причину, не раскрывая детали всем подряд.
Есть и дополнительная настройка PHP — display_errors. Она может быть включена на уровне хостинга или php.ini, и тогда сообщения будут появляться даже при корректных константах WordPress. Поэтому важно понимать: WordPress управляет своим уровнем отладки, но окончательное поведение зависит ещё и от PHP и конфигурации сервера.
Где менять настройки и почему это делается в wp-config.php
Константы отладки обычно задают в файле wp-config.php в корне сайта, рядом с настройками подключения к базе данных. Это стандартное место, потому что файл загружается до ядра WordPress и его настроек достаточно рано, чтобы повлиять на поведение системы.
Перед редактированием сделайте резервную копию wp-config.php. Ошибка в синтаксисе — лишняя кавычка, пропущенная точка с запятой, неверное место вставки — может полностью отключить сайт. Если сайт уже нестабилен, лучше сначала сохранить копию файла и, по возможности, проверить изменения на staging-копии.
Обычно строки вставляют перед строкой, где заканчивается настройка и начинается комментарий /* That's all, stop editing! Happy publishing. */. Если в файле уже есть похожие константы, не дублируйте их: WordPress не любит повторное объявление одинаковых настроек, а путаница в значениях только усложнит диагностику.
Как включить запись ошибок в лог и скрыть их от посетителей
Откройте wp-config.php и добавьте или измените такие строки:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Что делает каждая строка:
WP_DEBUGвключает отладочный режим WordPress;WP_DEBUG_LOGотправляет сообщения в файлwp-content/debug.log;WP_DEBUG_DISPLAYотключает вывод ошибок на страницу через WordPress;@ini_set( 'display_errors', 0 );дополнительно просит PHP не показывать ошибки в браузере, если хостинг это позволяет.
Последняя строка не обязательна, но на практике полезна, когда у хостинга или в конфигурации PHP уже включён вывод ошибок. Если сервер запрещает изменение этого параметра из PHP, строка просто не сработает — это нормально. Тогда нужно смотреть настройки хостинга или конфигурацию PHP отдельно.
После сохранения файла обновите проблемную страницу и проверьте, появился ли лог. Обычно WordPress создаёт файл wp-content/debug.log автоматически, если у веб-сервера есть права на запись в каталог wp-content. Если файл не появился, причина часто не в WordPress, а в правах доступа, владельце файлов или ограничениях хостинга.
Как проверить, что отладка работает правильно
Проверка должна состоять из двух частей: ошибки должны записываться, а посетитель не должен видеть подробности.
- Откройте проблемную страницу сайта или выполните действие, которое вызывает сбой.
- Проверьте, появился ли файл
wp-content/debug.log. - Откройте его и найдите свежие записи с временем, совпадающим с вашим действием.
- Убедитесь, что в браузере не отображаются предупреждения PHP, пути к файлам или служебные сообщения WordPress.
Если сайт всё ещё показывает ошибки на экране, проверьте настройки PHP на хостинге. Частая ситуация: в wp-config.php всё задано правильно, но на уровне PHP включён display_errors. Тогда WordPress может не выводить сообщения сам, а PHP всё равно покажет их посетителю.
Если лог не создаётся, проверьте права на запись в каталог wp-content. WordPress должен иметь возможность создать файл внутри этого каталога. На некоторых хостингах это зависит от владельца файлов и настроек PHP-FPM, а не только от числовых прав.
Когда лучше не оставлять отладку включённой
Режим отладки полезен для диагностики, но на рабочем сайте его не стоит держать включённым постоянно. Причина не в производительности как таковой, а в риске утечки внутренней информации. В лог могут попасть пути к файлам, имена классов, SQL-запросы, фрагменты данных и сообщения сторонних плагинов. Если файл debug.log окажется доступен из веба или попадёт в резервную копию без защиты, это уже лишняя информация для посторонних.
Поэтому после завершения диагностики обычно возвращают:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );Если вам нужен лог только на время разбирательства, этого достаточно. Не стоит включать отладку «на всякий случай» на неопределённый срок: журнал будет расти, а полезные записи смешаются с новыми сообщениями.
Что делать, если белый экран не даёт добраться до админки
При белом экране часто невозможно войти в админку, но это не мешает включить лог. wp-config.php редактируют напрямую через файловый менеджер хостинга, FTP/SFTP или SSH-доступ, если он есть. Именно в таких случаях отладочный лог особенно полезен: он показывает, какой плагин, тема или PHP-ошибка ломают загрузку сайта.
Если после включения отладки сайт по-прежнему пустой, а лог не появляется, проверьте ещё несколько вещей:
- не повреждён ли сам
wp-config.php; - есть ли доступ на запись в
wp-content; - не ограничивает ли хостинг создание файлов в каталоге сайта;
- не отключены ли ошибки на уровне PHP-FPM, Apache или Nginx;
- не вызвана ли проблема не WordPress, а базой данных или сервером.
Если ошибка связана с обновлением плагина или темы, лог обычно укажет на конкретный файл и строку. Это уже даёт направление: отключить проблемный плагин, временно переключить тему, проверить совместимость с версией PHP или откатить недавние изменения.
Как читать debug.log без лишнего шума
Файл debug.log может быстро наполняться повторяющимися сообщениями. Смотрите не на весь лог целиком, а на записи, которые совпадают по времени с вашим действием. Ищите:
PHP Fatal error— критическая ошибка, из-за которой страница может не загрузиться;WarningиNotice— не всегда ломают сайт, но часто указывают на проблемный код;- упоминания конкретного плагина или темы в пути к файлу;
- строку с номером файла и номером строки — это помогает быстро найти источник.
Если в логе много одинаковых сообщений, это не значит, что проблема одна и та же. Иногда один дефект вызывает цепочку предупреждений. В таком случае полезно сначала устранить первичную ошибку, а не каждое следствие по отдельности.
Для владельца сайта практический смысл отладки именно в этом: не просто «включить debug», а получить управляемый журнал ошибок, который помогает локализовать источник сбоя и при этом не раскрывает детали посетителям.
Коротко о безопасной схеме для рабочего сайта
Если нужен самый надёжный вариант, действуйте так: сделайте копию wp-config.php, включите WP_DEBUG и WP_DEBUG_LOG, отключите WP_DEBUG_DISPLAY, проверьте, что ошибки пишутся в wp-content/debug.log, и после диагностики сразу верните отладку в выключенное состояние. Если лог не создаётся или ошибки всё равно видны на экране, проверяйте уже не только WordPress, но и настройки PHP и ограничения хостинга.