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);

Так ошибки пишутся в wp-content/debug.log, но не показываются посетителям. Если сайт белеет после правки, первым делом проверьте именно этот файл: часто там видно, какой хук, шаблон или include падает.

Ещё одна частая ошибка — включать WP_DEBUG, но не чистить старые логи. В итоге вы ищете свежую поломку среди старого мусора. Удобнее после проверки отключить debug, удалить log и убедиться, что ошибка исчезла именно после правки, а не “сама”.

Для сложных случаев добавляйте логирование точечно: временно ставьте error_log() в нужный участок кода, а не держите debug всегда включённым. Это быстрее и безопаснее, чем ловить весь поток предупреждений подряд.

Хорошая привычка: отлаживайте на WP_DEBUG, а на живом сайте оставляйте только лог, без вывода на экран.