WP_DEBUG: когда включать, а когда он превращает сайт в витрину ошибок

WP_DEBUG: когда включать, а когда он превращает сайт в витрину ошибок

WP_DEBUG нужен не для “на всякий случай”, а для поиска причины бага. В рабочем режиме он часто раскрывает лишнее: пути к файлам, SQL-ошибки, предупреждения плагинов и темы. Если сайт открыт для посетителей, такой режим может помочь злоумышленнику собрать лишнюю информацию о структуре проекта.

Используйте так:
— на копии сайта или локально;
— на проде только при короткой диагностике;
— вместе с WP_DEBUG_LOG, чтобы ошибки писались в файл, а не на экран;
— после проверки сразу выключайте.

Полезная связка: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0); Так ошибки сохраняются в wp-content/debug.log, но не ломают интерфейс и не светят детали посетителям.

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

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