<b>WP_DEBUG включают не для «диагностики на глаз», а чтобы ловить ошибки до продакшена</b>

<b>WP_DEBUG включают не для «диагностики на глаз», а чтобы ловить ошибки до продакшена</b>

В wp-config.php достаточно поставить:
<code>define('WP_DEBUG', true);</code>
Но этого мало. Если просто включить вывод ошибок на живом сайте, можно показать посетителям путь к файлам, названия плагинов и детали PHP-сбоев. Для проверки на локалке это нормально, для боевого сайта — нет.

Нормальная связка обычно такая:
• WP_DEBUG — включает режим отладки
• WP_DEBUG_LOG — пишет ошибки в debug.log
• WP_DEBUG_DISPLAY — скрывает вывод на экран
• @ini_set('display_errors', 0); — дополнительно прячет ошибки PHP

Если сайт «падает» после правки темы или плагина, первым делом смотрят debug.log. Там видно, какой файл, строка и тип ошибки сломали страницу. Это быстрее, чем перебирать всё вручную и гадать, где конфликт.

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

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