WP_DEBUG включают слишком рано — и потом не понимают, откуда сыпятся ошибки

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

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

Частая ошибка — ждать, что WP_DEBUG сам исправит проблему. Он только показывает, где именно ломается код: тема, плагин, кастомный сниппет, шаблон. Если ошибка повторяется, смотри не только строку сообщения, но и цепочку вызовов: часто виноват не тот файл, который мелькает первым.

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

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