WP_DEBUG включает не только ошибки, но и риски, если оставить его включённым на живом сайте

WP_DEBUG включает не только ошибки, но и риски, если оставить его включённым на живом сайте

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

Базовая схема безопасной отладки такая:
— в wp-config.php включаете WP_DEBUG;
— отдельно задаёте WP_DEBUG_LOG, чтобы писать ошибки в debug.log;
— WP_DEBUG_DISPLAY оставляете выключенным, чтобы не показывать предупреждения на странице;
— после проверки возвращаете настройки обратно.

Частая ошибка — править проблему, не посмотрев лог. Если сайт падает после активации плагина, лог обычно сразу указывает на конкретный файл и строку. Это быстрее, чем отключать всё подряд и гадать, где сломалось 🛠

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

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