Как отключить отладку WordPress и убрать отладочные логи на рабочем сайте

На рабочем сайте отладка WordPress часто включается «на время» и потом забывается. В результате в wp-content/debug.log копятся ошибки, растёт нагрузка на диск, а иногда в логах остаются пути к файлам, фрагменты SQL-запросов и другие детали, которые лучше не светить наружу. Если сайт уже в продакшене, задача не в том, чтобы «потушить всё навсегда», а в том, чтобы отключить вывод отладки, сохранить контроль над ошибками и проверить, что ничего лишнего больше не пишется.

Когда это действительно проблема

Сценарий обычно один из трёх:

• в wp-config.php включён WP_DEBUG, а сайт давно открыт для посетителей;
• WP_DEBUG_LOG пишет в файл, который не чистят неделями;
• включён вывод ошибок на экран, и посетители видят предупреждения PHP вместо нормальной страницы.

Это не только вопрос аккуратности. На живом сайте отладка может мешать кешированию, засорять логи хостинга и создавать лишний шум при поиске реальных проблем. Если ошибка повторяется на каждой загрузке страницы, лог быстро разрастается до неудобных размеров.

Диагностика: что проверить перед правкой

Сначала убедитесь, что отладка действительно включена, а не просто где-то лежит старый файл debug.log. Проверять нужно не только сам файл, но и конфигурацию.

1. Откройте wp-config.php

Ищите строки вроде этих:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );

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

2. Проверьте наличие wp-content/debug.log

Если файл есть и активно растёт, значит кто-то или что-то продолжает писать ошибки. Сам по себе файл не опасен, но он полезен только в момент диагностики. На продакшене его лучше либо отключить, либо оставить под контролем и с ротацией.

3. Посмотрите, не включён ли вывод ошибок на сервере

На части хостингов PHP-ошибки могут логироваться отдельно, даже если WordPress уже не пишет в debug.log. Это нормально, но важно понимать, где именно остаются записи. Иначе можно «выключить» WordPress-отладку и удивляться, почему сообщения всё равно появляются в другом месте.

Пошаговое решение: как отключить отладку правильно

Ниже схема для обычного сайта на продакшене. Если вы сейчас чините баг, не удаляйте отладку вслепую — сначала сохраните нужные логи, потом отключайте.

Шаг 1. Переключите режимы в wp-config.php

Для рабочего сайта безопаснее оставить отладку выключенной и не показывать ошибки посетителям:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Если вы хотите оставить логирование только на короткий период, можно временно включить WP_DEBUG_LOG, но не держать это состояние неделями. Важно: WP_DEBUG_DISPLAY и display_errors лучше выключать отдельно, потому что они отвечают за показ ошибок на экране.

Шаг 2. Удалите или очистите старый debug.log

После отключения отладки старый файл можно удалить вручную или очистить. Если он нужен для истории, хотя бы заархивируйте его и перенесите вне веб-доступа. Оставлять накопленный лог в публичной директории — плохая практика.

Шаг 3. Проверьте настройки PHP на хостинге

Если хостинг позволяет управлять параметрами PHP, убедитесь, что display_errors выключен и на уровне PHP. Иногда WordPress-конфиг уже исправлен, а ошибки всё равно видны из-за настроек окружения.

Шаг 4. Если нужен контроль ошибок, используйте отдельный канал

Для рабочей диагностики лучше не держать постоянный debug.log, а включать отладку точечно: на время теста, на staging-копии или для конкретной сессии. Если у вас есть доступ к серверным логам, ориентируйтесь на них, а не на публичный файл в wp-content.

Что делать, если ошибки нужны, но сайт уже в продакшене

Иногда полностью отключать логирование неудобно: нужно поймать редкую ошибку плагина, проверить REST-запрос или понять, почему ломается шаблон. В таком случае лучше использовать короткое окно отладки и потом возвращать сайт в нормальный режим.

Если вы часто чистите сайт от дублей, мусора и технических хвостов, удобнее держать это в одном инструменте, чем вручную править конфиг и искать лишние записи по разным местам. Например, в Clearfy Pro есть набор функций для технической чистки WordPress: https://wpshop.ru/plugins/clearfy.

Проверка результата после внедрения

После правки не ограничивайтесь визуальной проверкой главной страницы. Нужно убедиться, что отладка не пишет в файл и не показывает сообщения посетителям.

• Откройте сайт в обычном окне браузера и в режиме инкогнито.
• Проверьте несколько страниц: главную, запись, архив, страницу с формой.
• Обновите проблемную страницу несколько раз и посмотрите, растёт ли debug.log.
• Если есть доступ по SSH или FTP, проверьте дату изменения файла debug.log.
• Посмотрите исходный HTML страницы: там не должно быть вставленных предупреждений PHP.

Если файл перестал изменяться, а ошибок на экране нет, значит базовая настройка сработала. Но если сайт всё равно пишет в лог, ищите не WordPress, а источник ошибки: плагин, тему, кастомный код или серверную конфигурацию.

Частые ошибки и как их исправить

WP_DEBUG выключили, а ошибки остались

Так бывает, когда сообщения идут не через WordPress, а через PHP или сервер. Проверьте display_errors в настройках хостинга и посмотрите серверные логи. Иногда причина вообще в автозагрузке плагина, который падает ещё до инициализации WordPress.

Отключили лог, но файл debug.log всё равно создаётся

Значит, где-то осталась старая конфигурация или код повторно включает логирование. Проверьте wp-config.php, MU-плагины и кастомные сниппеты. Если используется кэширование конфигурации на уровне хостинга, изменения могут применяться не сразу.

В лог попадают одни и те же ошибки

Это уже не проблема отладки, а проблема кода. Часто виноваты:

• устаревший плагин;
• конфликт темы и плагина;
• обращение к несуществующему индексу массива;
• ошибка в хуке, который срабатывает на каждой странице.

В таком случае отключение логов только скрывает симптом. Ошибку нужно локализовать и исправить.

После изменений сайт начал вести себя странно

Если вы редактировали wp-config.php, проверьте синтаксис файла. Одна лишняя кавычка или пропущенная точка с запятой может сломать сайт сильнее, чем сама отладка. Перед правкой всегда держите резервную копию файла.

Практические советы по безопасности и производительности

Отладка — это не только про удобство разработчика. На рабочем сайте она влияет на безопасность и эксплуатацию.

• Не храните debug.log в публичной директории дольше, чем нужно.
• Не включайте WP_DEBUG_DISPLAY на сайте с реальными посетителями.
• Если нужен временный лог, ограничьте окно теста и потом выключите его вручную.
• Не полагайтесь только на WordPress: проверяйте серверные логи и настройки PHP.
• Держите резервную копию wp-config.php перед любыми изменениями.

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

Мини-чек-лист перед публикацией изменений

• WP_DEBUG выключен.
• WP_DEBUG_LOG выключен или включён только временно.
• WP_DEBUG_DISPLAY выключен.
• display_errors отключён на уровне PHP.
• debug.log очищен или перенесён в безопасное место.
• На главных страницах нет PHP-предупреждений в HTML.
• Проблемный плагин или тема проверены отдельно, если ошибки продолжают появляться.

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