Сайт салона то показывает критическую ошибку, то молчит форма заявки — а в чате шепчут: включи WP_DEBUG в wp-config. Страшно трогать файл: опечатка убьёт витрину, а отладка вылезет гостям на экран. Игорь вставил одну строку define( ‘WP_DEBUG’, true ); — и клиентка написала, что сайт сломан. Ниже настройте официальную тройку констант: лог в wp-content/debug.log, чистая главная для посетителей — и за вечер получите понятную строку про виновный плагин, не показывая ошибки гостям.
Режим отладки WordPress (WP_DEBUG) — это не «сломать сайт для всех», а включить запись в тетрадь, которую читаете только вы через файловый менеджер хостинга. На живом сайте нужны три настройки вместе: WP_DEBUG true, WP_DEBUG_LOG true, WP_DEBUG_DISPLAY false и строка @ini_set( ‘display_errors’, 0 ). Без WP_DEBUG_LOG ошибки не попадут в wp-content/debug.log; без DISPLAY false посетители увидят предупреждения PHP на странице. После диагностики верните WP_DEBUG в false и уберите или защитите лог.
wp-config.php лежит в корне сайта рядом с папками wp-admin и wp-content. Его правят не из «Редактора тем», а в панели хостинга: «Файлы» → открыть файл → сохранить копию на диск. Честно: на рабочем сайте отладку держат ненадолго, только пока ищут причину сбоя.
- Разберите, зачем вам лог, когда белый экран или форма молчит
- Сравните три константы: что включить на время проверки
- Скопируйте бэкап и вставьте официальный блок в wp-config.php
- Найдите в debug.log имя плагина и решите, что отключить
- Выключите отладку и спрячьте debug.log от посторонних
- Выберите ручной блок или плагин WP Debugging, если страшно править конфиг
- Частые вопросы
- Можно ли включить wp debug без FTP и SSH?
- Чем WP_DEBUG_LOG отличается от WP_DEBUG_DISPLAY?
- Безопасно ли оставлять debug.log на сервере?
- Влияет ли отладка на скорость WordPress и SEO?
- Что делать, если debug.log не появился?
- Сколько держать WP_DEBUG включённым?
- Ломает ли одна опечатка в wp-config весь сайт?
Разберите, зачем вам лог, когда белый экран или форма молчит
Белый экран, сообщение «There has been a critical error» или форма, которая крутится и не отправляет данные, — типичные сигналы для владельца сайта услуг. Без записи ошибки вы гадаете: обновление плагина, тема, лимит памяти хостинга. WP_DEBUG включает подробные сообщения PHP; WP_DEBUG_LOG складывает их в файл, а не на экран.
На практике вы не читаете код целиком: ищете в debug.log слова plugins, themes, fatal error. Этого хватает, чтобы отключить один плагин в админке или написать в поддержку темы с цитатой из лога — такой результат сэкономит часы гадания на хостинге.
Сравните три константы: что включить на время проверки
В справочнике WordPress функция wp_debug_mode() прямо говорит: пока WP_DEBUG выключен, WP_DEBUG_LOG и WP_DEBUG_DISPLAY «не работают вообще». А если включить только WP_DEBUG и ничего больше, WP_DEBUG_DISPLAY по умолчанию true — предупреждения полезут в HTML. Русские гайды часто показывают одну строку; handbook (обновлён 23.09.2026) даёт полный блок с DISPLAY false.
| Константа | На время диагностики | Что это для вас |
|---|---|---|
| WP_DEBUG | true (без кавычек у значения) | Включает режим отладки; без неё лог не пишется |
| WP_DEBUG_LOG | true | Пишет ошибки в wp-content/debug.log |
| WP_DEBUG_DISPLAY | false | Не показывает ошибки посетителям на странице |
Типичная ошибка — написать define( ‘WP_DEBUG’, ‘true’ ); в кавычках. Строка ‘true’ для PHP не пустая, и режим ведёт себя не так, как вы ожидаете. Нужно именно boolean true и false без кавычек у слова true/false.
Скопируйте бэкап и вставьте официальный блок в wp-config.php
Workflow: бэкап wp-config → вставить блок выше комментария stop editing → сохранить → проверить сайт в режиме инкогнито → воспроизвести сбой → скачать debug.log.
- Шаг 1. Скачайте копию wp-config.php на компьютер или создайте wp-config.php.bak на хостинге. Привычка бэкапа перед любой правкой — в материале бэкап WordPress перед правками.
- Шаг 2. Откройте файл в файловом менеджере. Не трогайте блок с именем базы, пользователем и паролем. Найдите английский комментарий That’s all, stop editing! Happy publishing.
- Шаг 3. Непосредственно над этим комментарием вставьте блок из официального handbook (скопируйте целиком):
define( ‘WP_DEBUG’, true );
define( ‘WP_DEBUG_LOG’, true );
define( ‘WP_DEBUG_DISPLAY’, false );
@ini_set( ‘display_errors’, 0 );
- Шаг 4. Проверьте, что в файле нет второго define( ‘WP_DEBUG’ … ) — дубль даёт путаницу. На некоторых хостингах правят не тот wp-config (копия в подпапке); нужен файл в корне установки WordPress.
- Шаг 5. Сохраните и откройте главную в новой вкладке инкогнито. Жёлтых предупреждений PHP быть не должно. Если белый экран — сразу верните файл из бэкапа, не добавляйте новые строки.
- Шаг 6. Повторите действие, после которого ломается сайт: отправьте форму, откройте проблемную страницу, обновите плагин — как у вас проявляется сбой.
- Шаг 7. В файловом менеджере откройте папку wp-content и скачайте debug.log. Свежая запись внизу файла с датой и временем — признак, что лог работает.
В реальном проекте на shared-хостинге SSH не обязателен: тот же Garmtech и десятки панелей дают скачать debug.log кнопкой «Скачать».
Найдите в debug.log имя плагина и решите, что отключить
Откройте лог в блокноте на компьютере. Ищите строки с Plugin, themes, Fatal error, Warning. Например, путь wp-content/plugins/contact-form-7/… намекает на форму заявок. Дальше: «Плагины» → деактивировать подозрительный → снова проверить сайт. Если админка не открывается, переименуйте папку плагина в wp-content/plugins через файловый менеджер (добавьте -off к имени) — WordPress отключит его без входа в панель.
Связка с белым экраном: на странице пусто, а в логе есть текст — вы уже не гадаете. Скопируйте 3–5 строк в тикет хостинга или разработчику. Перед массовым отключением плагинов сделайте резервную копию WordPress, если её ещё нет.
Выключите отладку и спрячьте debug.log от посторонних
После диагностики верните боевой режим: замените блок на define( ‘WP_DEBUG’, false ); или удалите добавленные строки. Официальные рекомендации для production: WP_DEBUG false, WP_DEBUG_LOG false, WP_DEBUG_DISPLAY false. Файл debug.log может содержать пути сервера и фрагменты данных из форм — не оставляйте его годами в публичной папке.
Минимум без «DevOps»: удалите debug.log или скачайте архив к себе и удалите с сервера. Если хостинг позволяет, ограничьте доступ к файлу через .htaccess (Deny from all) или правами 600. Продвинутый вариант — путь к логу вне web root; для новичка чаще достаточно выключить WP_DEBUG и убрать файл.
Параллельно имеет смысл убрать опасный редактор файлов в админке и перед крупными правками поднять тестовую копию WordPress или включить режим обслуживания, если боитесь, что гости увидят полусломанную витрину.
Выберите ручной блок или плагин WP Debugging, если страшно править конфиг
Плагин WP Debugging на wordpress.org при активации прописывает те же константы в wp-config и снимает при деактивации. Плюс: меньше ручного копирования. Минус: ещё одно обновление в списке плагинов и риск забыть выключить. Ручной блок из handbook прозрачнее: вы видите каждую строку в файле.
Query Monitor и тяжёлые профайлеры для владельца салона обычно лишние: задача — один раз получить текст ошибки, а не изучать каждый запрос к базе. Если файловый менеджер недоступен, напишите в поддержку хостинга с просьбой включить лог по их инструкции.
Успех выглядит так: в wp-config блок из четырёх строк стоит выше stop editing; сайт в инкогнито без жёлтых блоков; после повторения проблемы в wp-content/debug.log есть свежая запись; после работ вы вернули WP_DEBUG в false и убрали или защитили лог. Если некогда лезть в конфиг на боевом домене, опишите симптомы через форму контактов (мессенджер, без звонка) или загляните в раздел услуг по сопровождению WordPress. Ещё гайды по сайту и SEO — в разделе статей; короткие ответы по ходу — в канале t.me/DikiiTelegram.
Материал проверен: Андрей Дикий (создаёт сайты и продвигает их статьями, SEO/GEO).
На что опирались: developer.wordpress.org (Debugging in WordPress, wp-config, wp_debug_mode); ru.wordpress.org (отладка в WordPress); wordpress.org/plugins/wp-debugging; wp-kama.ru handbook wp-debug; support.garmtech.com про debug.log; GitHub WordPress Advanced-administration-handbook. Частотность: Яндекс Вордстат, прогон 2026-10-04 (MCP недоступен, точные показы не верифицированы).
Частые вопросы
Можно ли включить wp debug без FTP и SSH?
Да, если хостинг даёт файловый менеджер в панели: откройте wp-config.php, вставьте блок, сохраните. SSH не обязателен для скачивания debug.log из wp-content.
Чем WP_DEBUG_LOG отличается от WP_DEBUG_DISPLAY?
LOG пишет ошибки в файл на сервере. DISPLAY решает, показывать ли их в HTML страницы. На живом сайте на время проверки LOG true, DISPLAY false.
Безопасно ли оставлять debug.log на сервере?
Ненадолго для диагностики — да, если отладку потом выключили. Навсегда — нет: по URL иногда можно скачать лог; удалите файл или закройте доступ после исправления.
Влияет ли отладка на скорость WordPress и SEO?
Пока WP_DEBUG true, сайт пишет больше служебной информации; для поисковиков важнее, чтобы гостям не показывались ошибки на экране. Держите режим включённым часы, не месяцы.
Что делать, если debug.log не появился?
Проверьте, что WP_DEBUG именно true без кавычек, блок стоит до stop editing, и папка wp-content доступна для записи (права на хостинге). Воспроизведите ошибку ещё раз и обновите список файлов.
Сколько держать WP_DEBUG включённым?
До тех пор, пока не поймали ошибку в логе и не приняли решение: обновить, отключить плагин или передать текст в поддержку. Затем сразу верните false и уберите лог.
Ломает ли одна опечатка в wp-config весь сайт?
Синтаксическая ошибка в PHP даёт белый экран. Поэтому бэкап файла перед правкой обязателен: вернули старую копию — сайт снова открывается, можно вставить блок заново по чеклисту.
