WP_DEBUG: как включать отладку, не ломая сайт и не светя ошибки наружу

WP_DEBUG: как включать отладку, не ломая сайт и не светя ошибки наружу

WP_DEBUG нужен не для «включить и забыть», а для точной диагностики. Базовая связка такая: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false); @ini_set('display_errors', 0);

Дальше смотрите не на фронт, а в файл debug.log. Там быстро ловятся:
— конфликт плагинов и темы;
— fatal error после правки functions.php;
— предупреждения о старом коде, который пока не валит сайт, но уже шумит.

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

Ещё один полезный приём — проверять, не дублируются ли сообщения в логах. Если одна и та же ошибка повторяется сотни раз, ищите не «симптом», а место, где код запускается на каждом хите: cron, виджет, хук в цикле, AJAX-запрос.

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