Как включить журнал ошибок WordPress без показа ошибок посетителям

Сайт «то работает, то белый экран», хостинг пишет «включите отладку», а правка wp-config.php пугает: сломаю всё и клиенты увидят красные ошибки прямо над каталогом. Олег из магазина инструментов включил одну строку WP_DEBUG — и покупатель написал «у вас сайт сломан». Решение не в показе ошибок на витрине, а в журнале в файле debug.log: настройте три строки в конфиге — и получите чистую главную для гостей и понятную запись с именем плагина. За 15-20 минут вы сможете сами найти причину сбоя без программиста.

Журнал ошибок WordPress включают связкой из трёх настроек в wp-config.php: WP_DEBUG true (режим отладки), WP_DEBUG_LOG true (писать в файл) и WP_DEBUG_DISPLAY false (не показывать гостям). Без явного DISPLAY false WordPress по умолчанию всё равно выводит ошибки на экран — даже если лог уже пишется. Файл лежит в wp-content/debug.log и появляется только после первой записи. После ремонта верните DEBUG и LOG в false и закройте лог от прямого доступа из интернета.

Представьте магазин с витриной и подсобкой. Витрина — то, что видит покупатель. Подсобка — журнал, куда сотрудник записывает, что сломалось. Слушайте сайт через подсобку, а не через витрину: ошибки остаются в файле, а страницы для клиентов выглядят как обычно. Ниже — один сценарий без трёх разных методов и без DevOps-лексики.

Зачем владельцу услуг журнал ошибок, если сайт «просто глючит»

Главная боль — гадать вслепую. Форма на странице контактов молчит, главная иногда пустая, а в админке всё зелёное. Без журнала вы платите за «посмотрите сами» и теряете заявки. С включённым логом видно конкретику: какой плагин, какая строка, после какого обновления.

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

Разберите три настройки: что видит гость и что остаётся в файле

Типичная ошибка — включить только WP_DEBUG и думать, что ошибки «куда-то записались». На самом деле без WP_DEBUG_LOG запись в debug.log не идёт, а без WP_DEBUG_DISPLAY false посетители видят жёлтые и красные предупреждения PHP. Это и случилось с Олегом: одна строка — и каталог испорчен для клиентов.

Важно: true и false пишут без кавычек. Избегайте строки ‘false’ в кавычках — в PHP это «истина», и отладка останется включённой, хотя вы думали иначе.

Сохраните копию wp-config.php до любых правок

Страх «сломаю wp-config» снимается одним действием: скачать файл до правки. Используйте файловый менеджер хостинга или FTP — Word не подходит, нужен обычный текст. Если после сохранения сайт выдаёт белый экран — загружаете старую копию обратно. Подробный разбор — в материале про бэкап WordPress перед правками.

1. Зайдите в панель хостинга → «Файловый менеджер» или подключитесь по FTP (FileZilla и аналоги).
2. Откройте корень сайта (часто public_html или www) и найдите файл wp-config.php.
3. Скачайте его на компьютер с именем вроде wp-config-backup-2026-09-17.php; при сезоне продаж добавьте полный бэкап сайта через плагин или хостинг.
4. Запомните: править можно только блок выше строки «Это всё, дальше не редактируем» / «That’s all, stop editing». Ниже — служебная зона, туда не лезем.

Одна лишняя точка с запятой в конфиге даёт белый экран. С копией на диске восстановление — минута.

Вставьте в wp-config.php блок из четырёх строк

Боль «клиенты увидят ошибки» закрывается официальной связкой из справочника WordPress (обновлён в июле 2025): лог включён, показ на экране выключен, плюс запрет вывода через ini_set.

define(‘WP_DEBUG’, true);
define(‘WP_DEBUG_LOG’, true);
define(‘WP_DEBUG_DISPLAY’, false);
@ini_set(‘display_errors’, 0);

Workflow: бэкап wp-config → открыть файл в менеджере → вставить блок выше строки «stop editing» → сохранить → открыть сайт в режиме инкогнито → убедиться, что нет PHP-текста → обновить проблемную страницу → открыть wp-content/debug.log → прочитать последние строки → после ремонта вернуть false

1. Откройте wp-config.php в редакторе хостинга (не Word — нужен обычный текст).
2. Найдите строку /* That’s all, stop editing! Happy publishing. */ или русский аналог.
3. Непосредственно выше вставьте четыре строки из блока (true/false без кавычек).
4. Сохраните файл. Если редактор спрашивает кодировку — оставьте UTF-8.
5. Откройте главную в режиме инкогнито (вы не залогинены как админ). Не должно быть предупреждений и «Deprecated» над шапкой.
6. Воспроизведите сбой: обновите каталог, отправьте тестовую заявку, зайдите в админку — что обычно ломается.
7. Через файловый менеджер откройте wp-content/debug.log. Если файла нет — обновите страницу ещё раз: он создаётся при первой записи.

Если правка wp-config пугает, плагин Debug Log Manager из каталога WordPress.org включает те же настройки и показывает лог в админке.

Найдите debug.log и поймите, что написано в последних строках

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

Читайте снизу вверх. Ищите дату, «Fatal error» или «Warning» и путь wp-content/plugins/имя-плагина/. Дальше — отключить плагин, откатить версию (см. автообновление плагинов) или спросить хостинг про версию PHP.

Типичные сообщения и первый шаг:

• Fatal error в файле плагина — отключите плагин, сайт часто оживает сразу; потом обновите или замените.
• Allowed memory size exhausted — нехватка памяти PHP; временно увеличивают лимит в настройках хостинга, но ищут тяжёлый плагин.
• Deprecated после смены версии PHP — плагин устарел; нужно обновление от автора или замена.

Не оставляйте debug.log доступным по прямой ссылке: внутри пути и версии. Закройте файл через .htaccess или попросите хостинг.

Выключите отладку и убедитесь, что витрина снова в норме

Официально WP_DEBUG на живом сайте держат включённым только на время диагностики. Лог растёт, сервер пишет лишнее, а в файле копятся подсказки для злоумышленников.

1. Когда причина найдена и плагин исправлен или отключён, верните в wp-config.php: define(‘WP_DEBUG’, false); и define(‘WP_DEBUG_LOG’, false);
2. Удалите или очистите старый debug.log (сначала сохраните копию, если передаёте специалисту).
3. Снова проверьте главную и форму заявки в инкогнито; если обновляли ядро перед сбоем — сверьтесь с обновлением WordPress без поломки.

Ориентир результата: в инкогнито нет PHP-текста; в debug.log есть свежая запись; вы назвали плагин из лога; после ремонта WP_DEBUG снова false. Если белый экран остался — пришлите хвост лога через форму на сайте или в Telegram. Настройка на /uslugi, другие гайды — в /stati/.

Материал проверен: Андрей Дикий (сайты WordPress, SEO/GEO).
Источники по теме: developer.wordpress.org (Debug WordPress, wp_debug_mode, wp-config), ru.wordpress.org (отладка, редактирование wp-config), каталог Debug Log Manager; частота запросов — Яндекс Вордстат, 2026-09-17 (MCP недоступен, LSI по SERP).

Частые вопросы

Как включить wp debug log в WordPress безопасно?

Добавьте в wp-config.php выше строки «stop editing» четыре строки: WP_DEBUG true, WP_DEBUG_LOG true, WP_DEBUG_DISPLAY false и @ini_set(‘display_errors’, 0). Сначала скачайте копию файла. Проверьте сайт в инкогнито — гости не должны видеть технический текст.

Где находится debug.log в WordPress?

По умолчанию в папке wp-content/debug.log рядом с темами и плагинами. Файл появляется после первой записи ошибки — если его нет, обновите проблемную страницу и снова откройте папку через FTP или файловый менеджер хостинга.

Безопасно ли включать WP_DEBUG на работающем сайте?

На короткое время диагностики — да, если DISPLAY false и лог не доступен из браузера. Официально не рекомендуют держать отладку месяцами: файл растёт, нагрузка выше. После ремонта верните DEBUG и LOG в false.

Как отключить показ ошибок WordPress посетителям?

Обязательно define(‘WP_DEBUG_DISPLAY’, false); — одного WP_DEBUG мало, потому что DISPLAY по умолчанию true. Дополнительно @ini_set(‘display_errors’, 0); как в примере из справочника WordPress. Проверка — режим инкогнито без входа в админку.

Что делать, если debug.log разросся до гигабайта?

Выключите WP_DEBUG и WP_DEBUG_LOG, скачайте хвост файла для анализа, остальное удалите или обнулите через хостинг. Ищите повторяющуюся ошибку в цикле — часто виноват плагин, который пишет предупреждение на каждый просмотр.

Можно ли смотреть журнал без FTP?

Да: плагин Debug Log Manager показывает debug.log в админке WordPress. Альтернатива — файловый менеджер в панели хостинга без отдельной программы. Путь к файлу тот же — wp-content/debug.log.

Почему лог пустой, хотя сайт не работает?

Возможно, ошибка настолько ранняя, что WordPress не успевает писать в лог, или правки в wp-config с синтаксической ошибкой. Восстановите бэкап конфига. Также проверьте логи хостинга в панели — иногда fatal error виден только там.