WP_DEBUG помогает ловить ошибки, но без правил быстро превращается в шум

WP_DEBUG помогает ловить ошибки, но без правил быстро превращается в шум

Включать его стоит не для «проверить на глаз», а чтобы увидеть, где ломается шаблон, плагин или запрос. В wp-config.php задайте минимум: define('WP_DEBUG', true); и отдельно WP_DEBUG_LOG, чтобы сообщения уходили в файл, а не на экран.

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

Что проверять в логе в первую очередь:
• Missing argument — часто ошибка в теме или кастомном хуке
• Undefined variable — переменная не задана до использования
• Deprecated — код не всегда падает, но уже живёт на грани
• Cannot modify header information — проблема с выводом до заголовков

Если лог пустой, а ошибка есть, смотрите не только WP_DEBUG, но и права на запись, место файла логов и наличие вывода в PHP-ошибки сервера. Часто причина прячется не в WordPress, а в стороннем коде.

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