Представьте ситуацию: вы заходите на свой сайт, а там — белый экран. Ничего не грузится, панель администратора не открывается. Или, что ещё хуже, клиенты жалуются, что форма заявки перестала отправляться. Тишина. Вы в панике гуглите «белый экран смерти WordPress», находите кучу советов, но боитесь что-то трогать в коде.
Знакомо?
Я сам через это проходил. Лет пять назад, когда только начинал возиться с WordPress, один неудачный плагин для кэширования положил мне весь интернет-магазин. Клиенты не могли оформить заказ, а я сидел и тупо смотрел в пустой экран. Поддержка хостинга разводила руками. Спасла меня именно настройка WP_DEBUG. Она показала, в чём конкретно ошибка, и я исправил её за пять минут.
С тех пор для меня включение WP_DEBUG — это первый шаг, когда сайт начинает «чудить». И сегодня я расскажу, как это сделать правильно, чтобы не навредить и быстро найти проблему.
Что такое WP_DEBUG и зачем он вообще нужен?
Если объяснять просто, WP_DEBUG — это специальный режим работы WordPress, который заставляет CMS показывать все ошибки, предупреждения и уведомления. В обычной жизни WordPress скрывает их от пользователей, чтобы не портить впечатление. Но когда что-то ломается, без этого режима вы как слепой котёнок.
WP_DEBUG выводит три типа сообщений:
- Ошибки (Errors) — критические проблемы, которые нужно исправлять немедленно.
- Предупреждения (Warnings) — что-то работает не оптимально, но сайт не падает.
- Уведомления (Notices) — мелочи, которые лучше поправить, чтобы не было проблем в будущем.
Для разработчика или владельца бизнеса, который хочет разобраться с проблемой самостоятельно, WP_DEBUG — это буквально фонарик в тёмной комнате.
Как включить WP_DEBUG: три рабочих способа
Есть несколько путей. Я покажу самые надёжные, которые не сломают сайт, если делать всё аккуратно.
Способ 1: Через файл wp-config.php (рекомендую)
Это основной и самый правильный метод. Нам нужно отредактировать конфигурационный файл WordPress.
define( 'WP_DEBUG', false ); или похожую. Если её нет — не страшно./ That's all, stop editing! Happy publishing. / вставьте такой код:define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
Разберём, что здесь написано:
- WP_DEBUG true — включает сам режим отладки.
- WP_DEBUG_LOG true — все ошибки будут записываться в специальный лог-файл, а не выводиться на экран. Это важно для безопасности, чтобы посетители не видели технические детали.
- WP_DEBUG_DISPLAY false — отключает показ ошибок на экране.
Всё. Теперь все ошибки будут записываться в файл debug.log, который появится в папке /wp-content/.
Способ 2: Через плагин (для тех, кто не хочет лезть в код)
Если вам страшно трогать файлы, можно использовать плагины. Например, WP Debugging или Query Monitor. Они делают то же самое, но через интерфейс.
Я, честно говоря, предпочитаю первый способ. Плагины — это дополнительная нагрузка на сайт и потенциальная дыра в безопасности. Но для быстрого теста — вариант.
Способ 3: Через FTP-клиент
Если у вас нет доступа к панели управления хостингом, но есть FTP (например, FileZilla), вы можете скачать файл wp-config.php на компьютер, отредактировать его и загрузить обратно. Принцип тот же, что в первом способе.
Как настроить WP_DEBUG правильно: мои лайфхаки
Мало просто включить — нужно настроить так, чтобы не навредить.
Куда смотреть логи?
После включения WP_DEBUG_LOG в папке /wp-content/ появится файл debug.log. Вы можете открыть его в блокноте. Если ошибок много, файл может быть большим. Я рекомендую скачивать его через FTP, а не открывать прямо на хостинге — так быстрее.
Как отключить показ ошибок на живом сайте?
Это критично. Если вы включите[/text]WP_DEBUG_DISPLAY в true на рабочем сайте, посетители увидят кучу страшного текста вместо вашей красивой шапки. Более того, злоумышленники могут узнать версию PHP, пути к папкам и другую информацию.
Поэтому на проде всегда ставьте false.
Что делать, если лог пустой?
Бывает. Проверьте:
- Правильно ли вы вставили код (лишние пробелы или точки с запятой могут сломать всё).
- Обновите страницу, на которой была проблема.
- Проверьте права на папку wp-content — она должна быть доступна для записи.
Типичные ошибки, которые показывает WP_DEBUG
Когда вы впервые включите отладку, глаза могут разбежаться. Вот самые частые сообщения и что они значат:
- "Fatal error: Uncaught Error: Call to undefined function" — вы пытаетесь вызвать функцию, которой нет. Чаще всего — из-за несовместимости плагина или темы.
- "Warning: Cannot modify header information" — проблема с отправкой заголовков. Часто возникает из-за лишних пробелов в файлах functions.php или config.php.
- "Notice: Undefined variable" — несерьёзная ошибка, но лучше её исправить, чтобы не было сюрпризов.
Важно: не оставляйте WP_DEBUG включённым навсегда. После того как вы нашли и исправили проблему, верните настройки обратно:
define( 'WP_DEBUG', false ); define( 'WP_DEBUG_LOG', false ); define( 'WP_DEBUG_DISPLAY', true );
Или просто удалите эти строки, если их не было изначально.
Когда WP_DEBUG не помогает?
Честно скажу, бывают ситуации, когда даже этот режим не показывает проблему. Например:
- Белый экран из-за нехватки памяти. Тут смотрите в логи хостинга, а не WordPress.
- Проблемы с кэшированием. WP_DEBUG не видит кэш браузера или сервера.
- Ошибки в .htaccess. Это уже к серверным настройкам.
Но в 90% случаев WP_DEBUG решает вопрос. Я сам с его помощью находил конфликты плагинов, кривые обновления тем и даже ошибки в собственных правках.
Что в итоге?
WP_DEBUG — это не магия, а просто инструмент. Как отвёртка или мультиметр. Если знать, куда смотреть, он экономит часы нервотрёпки.
Не бойтесь включать его, когда сайт падает. Делайте это по инструкции, выключайте после ремонта — и всё будет хорошо.
Если вам нужна помощь с настройкой сайта на WordPress, оптимизацией или разработкой — я и команда Wenesis всегда рядом. Мы не просто чиним, мы делаем так, чтобы проблемы не возвращались.
Обращайтесь.
Добавить комментарий