Если на сайте внезапно начали появляться предупреждения PHP, пути к файлам темы или плагинов, а иногда и полный стек ошибок, проблема почти всегда в том, что отладка включена на боевом сайте. Это не только выглядит неаккуратно: такие сообщения помогают быстро понять структуру проекта, версии библиотек и слабые места в коде.
В WordPress это обычно связано с настройками в wp-config.php, а не с каким-то отдельным плагином. Поэтому решение лучше начинать с проверки конфигурации, а не с установки очередного «скрывающего ошибки» расширения.
Что именно нужно проверить в первую очередь
Сначала убедитесь, что проблема действительно в стандартной отладке WordPress, а не в настройках PHP или серверного логирования. На практике чаще всего встречаются три сценария: сайт показывает предупреждения на экране, ошибки пишутся в файл, но не должны быть видны посетителям, или включён режим, при котором WordPress сохраняет лог и одновременно выводит сообщения в HTML.
Диагностика в wp-config.php
Откройте wp-config.php и найдите строки, связанные с отладкой. Обычно это WP_DEBUG, WP_DEBUG_LOG и WP_DEBUG_DISPLAY. Если они заданы вручную, важно смотреть не только на значение, но и на порядок строк: константы должны быть определены до строки /* That's all, stop editing! Happy publishing. */.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
@ini_set( 'display_errors', 1 );Такой набор допустим на локальной машине, но на продакшене он почти гарантированно приведёт к выводу служебной информации в браузер. Если сайт уже в рабочем режиме, это нужно убрать.
Проверка на уровне PHP
Даже если в WordPress всё выключено, сервер может продолжать показывать ошибки через display_errors. Это отдельная настройка PHP. На shared-хостинге её часто меняют через панель управления, на VPS — в php.ini, .user.ini или конфигурации пула PHP-FPM.
Если вы видите сообщения вида Deprecated, Warning или Notice прямо на странице, проверьте именно этот уровень. WordPress не всегда может полностью перекрыть серверный вывод.
Как отключить вывод ошибок в WordPress безопасно
Базовая задача простая: оставить логирование, если оно нужно, но убрать показ ошибок посетителям. Для этого в wp-config.php обычно достаточно заменить набор констант на более безопасный вариант.
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Если отладка вам не нужна вообще, можно отключить и логирование. Но на практике удобнее оставить лог в wp-content/debug.log на время проверки после обновлений темы, плагинов или PHP-версии. Главное — не показывать ошибки на фронтенде.
Когда лог нужен, а когда нет
Лог полезен после обновления ядра, смены версии PHP, установки нового плагина или правки шаблонов. Если сайт стабилен, а лог только заполняется старыми предупреждениями, его лучше отключить или хотя бы регулярно чистить. Иначе вы будете искать реальные проблемы среди мусора.
| Подход | Что делает | Когда использовать | Компромисс |
|---|---|---|---|
Только WP_DEBUG = false | Отключает стандартную отладку WordPress | Обычный продакшен | Не всегда убирает серверные ошибки |
WP_DEBUG_LOG = true, WP_DEBUG_DISPLAY = false | Пишет ошибки в лог, не показывает их посетителям | После обновлений и при поиске багов | Нужно следить за размером лога |
Отключение display_errors на уровне PHP | Убирает вывод ошибок сервером | Если ошибки всё равно видны | Зависит от хостинга и конфигурации |
Пошаговое решение: что менять и в каком порядке
Шаг 1. Сделайте резервную копию wp-config.php
Перед правкой сохраните копию файла. Это не формальность: одна лишняя кавычка или точка с запятой в wp-config.php может положить сайт в белый экран. Если работаете через FTP, скачайте файл локально. Если через SSH, сделайте копию на сервере.
Шаг 2. Уберите вывод отладочных сообщений
Проверьте, чтобы в конфиге не было WP_DEBUG_DISPLAY со значением true и не было принудительного включения display_errors. Для продакшена безопаснее явно задать отключение:
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Шаг 3. Если нужно, оставьте лог только для админов
Иногда удобно временно включать логирование на короткий срок, чтобы поймать ошибку после обновления. В таком случае не открывайте файл лога публично и не храните его дольше необходимого. Файл wp-content/debug.log должен быть доступен только тем, кто реально занимается поддержкой сайта.
Шаг 4. Проверьте настройки хостинга
Если после правки ошибки всё равно видны, ищите их на уровне PHP. На некоторых хостингах display_errors включён в панели управления отдельно от WordPress. Тогда нужно отключить его там или через .user.ini, если провайдер это поддерживает.
display_errors = Off
log_errors = OnТакой вариант обычно оставляет запись в логах, но не показывает сообщения на сайте. Это нормальная схема для продакшена.
Как проверить, что решение сработало
После изменений откройте несколько страниц сайта в обычном браузере и в режиме инкогнито. Проверьте главную, запись, архив и страницу с формой, если она есть. На экране не должно быть ни Warning, ни Notice, ни путей вида /home/user/public_html/wp-content/themes/....
- Откройте страницу с параметром, который раньше вызывал предупреждение.
- Проверьте исходный код страницы на наличие служебных сообщений.
- Посмотрите, создаётся ли новый
debug.log, если логирование оставлено включённым. - Убедитесь, что админка работает без белых экранов и фатальных ошибок.
Если у вас есть доступ к SSH, можно быстро проверить наличие лога и его размер:
ls -lh wp-content/debug.log
tail -n 50 wp-content/debug.logЕсли лог растёт после каждого обновления страницы, значит, проблема не в показе ошибок, а в самом коде темы или плагина. В этом случае отладку не просто выключают, а находят источник предупреждений.
Частые ошибки и как их исправить
Оставили WP_DEBUG включённым «на время»
Это самая частая причина. Файл правят один раз, потом забывают. В результате сайт месяцами светит служебные сообщения. Исправление простое: проверьте wp-config.php после любых работ и не держите debug включённым без необходимости.
Отключили WordPress, но не отключили PHP
Иногда в wp-config.php всё уже выключено, а предупреждения всё равно видны. Значит, вывод идёт из PHP или веб-сервера. Ищите display_errors в php.ini, .user.ini или панели хостинга.
Сломали синтаксис в wp-config.php
После правки сайт может перестать открываться, если случайно удалить точку с запятой или кавычку. В таком случае откатите резервную копию и правьте файл аккуратно. Если работаете через редактор в панели хостинга, лучше не редактировать wp-config.php без бэкапа.
Путают логирование и вывод ошибок
WP_DEBUG_LOG не означает, что ошибки должны быть видны посетителям. Это разные вещи. Для безопасной диагностики обычно нужен лог без вывода на экран. Если это не разделять, можно случайно оставить уязвимую конфигурацию на продакшене.
Что делать, если ошибки появляются снова после обновлений
Если после обновления темы или плагина предупреждения возвращаются, не лечите симптом отключением всего подряд. Сначала найдите конкретный источник: несовместимая версия PHP, старый плагин, устаревший шаблон или кастомный код в functions.php. Часто проблема не в WordPress как таковом, а в одном фрагменте кода, который давно пора переписать.
Для регулярной поддержки удобно держать отладку выключенной, а включать её только на короткое время при проверке изменений. Это нормальная практика для боевого сайта: меньше шума, меньше риска случайно показать внутренности проекта пользователям и поисковым роботам.