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

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

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

Рабочая схема такая:
• включить debug только на копии сайта или на короткое окно проверки;
• сразу добавить WP_DEBUG_LOG, чтобы ошибки уходили в отдельный файл;
• при необходимости включать WP_DEBUG_DISPLAY только локально, а не на сайте с посетителями;
• после исправления — вернуть настройки обратно.

Частая ошибка — искать проблему по одной строке в логе. Смотрите контекст: повторяется ли ошибка, какой файл её вызывает, появляется ли она после конкретного действия в админке или на фронте. Если лог пустой, это тоже сигнал: ошибка может быть не PHP-уровня, а в JS, кэше или конфликте хуков.

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

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