Содержание

Белый экран или ошибка в WordPress? Пора завести собственный debug.log. В статье мы разобрали настройку журнала ошибок и показали, как правильно вести отладку на своём сайте или VPS, чтобы быстрее находить и устранять проблемы.

Введение

Представьте: вы заходите на свой WordPress-сайт, а он внезапно приветствует вас белым экраном или загадочным сообщением об ошибке. Что случилось и как это исправить? Непонятно. В такие моменты на помощь приходит журнал ошибок, который записывает все сбои и предупреждения. Разобрав записи в логе, вы быстро поймёте, какой плагин или скрипт вызвал проблему, и сможете её решить.

В статье привели пошаговую инструкцию по включению режима отладки в WordPress и созданию собственного файла логов debug.log, чтобы ошибки сайта записывались отдельно от общесистемных логов сервера. Рассказали, как просматривать и анализировать эти записи.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Зачем отделять логи WordPress от системных

Веб-сервер (Apache, Nginx) и PHP обычно ведут свои системные журналы ошибок. Однако сообщения от вашего сайта WordPress могут затеряться среди прочих записей, особенно на виртуальном хостинге. Более того, на большинстве хостингов показ ошибок PHP для посетителей отключён, и без специального лога вы можете вообще не узнать о проблеме, пока сайт не перестанет работать. Поэтому в WordPress предусмотрен встроенный механизм отладки. При активации определённых настроек движок будет сохранять все ошибки и предупреждения в отдельный файл внутри вашего сайта. С персональным логом WordPress вы получите всю информацию об ошибках именно вашего проекта, в одном месте и в понятном виде, и при этом вы не зависите от настроек системных логов сервера.

Неявные ошибки, такие как различные предупреждения и уведомления уровня Notice, никак не проявляются внешне, но всё равно свидетельствуют о проблемах в коде. Отдельный файл debug.log будет фиксировать их за кулисами, позволяя вам вовремя увидеть и исправить потенциальную ошибку, прежде чем она выльется в серьёзный сбой.

Как включить журнал ошибок WordPress

Прежде чем начать, сделайте бекап файла wp-config.php. Скопируйте исходный wp-config.php в безопасное место, чтобы при необходимости быстро вернуть всё обратно.

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

Теперь найдите в файле строку с WP_DEBUG. В типичной установке WordPress там уже есть запись:

define('WP_DEBUG', false);

Она находится ближе к концу, перед комментариями "That's all, stop editing...". Замените false на true:

define('WP_DEBUG', true);

Если такой строки не оказалось, вы можете добавить её сами, желательно прямо перед строкой "That's all, stop editing! Happy blogging.". Эта константа включает режим отладки в WordPress и заставляет движок реагировать на все ошибки PHP.

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

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

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

Не дублируйте существующие параметры. Если в wp-config.php уже была строка с WP_DEBUG или WP_DEBUG_DISPLAY, отредактируйте их, а не добавляйте вторую копию. Каждая константа должна определяться в файле только один раз.

После внесения изменений сохраните файл и загрузите его обратно на сервер, если редактировали локально. На этом настройка завершена. Теперь ваш WordPress запущен в режиме отладки, но ошибки не показываются пользователям, а тихонько протоколируются в отдельный файл. Как только на сайте произойдёт какая-либо ошибка или предупреждение, система запишет соответствующую строку в debug.log в директории wp-content.

По умолчанию файл debug.log создаётся в общедоступной папке wp-content. Вы можете задать другой путь и имя для журнала, если хотите спрятать его от посторонних. Например:

define('WP_DEBUG_LOG', '/tmp/wp-errors.log');

В этом случае WordPress будет записывать ошибки в указанный файл, в примере это директория /tmp на сервере. Выбранный каталог должен существовать и быть доступен для записи веб-сервером. Новичкам не нужно менять расположение лога, но в целях безопасности на продакшене иногда выносят файл журнала за пределы папки сайта.

Когда вы завершите отладку и решите, что отдельный лог больше не нужен, не забудьте отключить его. Для этого достаточно вернуть константу WP_DEBUG обратно в false и при желании отключить WP_DEBUG_LOG. Вы также можете просто удалить или закомментировать добавленные строки. На постоянной основе держать сайт в режиме отладки нежелательно. Логирование может немного снижать производительность и со временем занимает место на диске. Включайте его на время поиска проблемы, а затем выключайте либо регулярно очищайте лог.

Просмотр и анализ debug.log

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

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

[20-Apr-2025 15:08:59 UTC] PHP Notice: Undefined index: foo in /wp-content/themes/mytheme/functions.php on line 123

Разберём этот пример. Указана дата и время — 20 апреля 2025, 15:08:59 (UTC), затем идёт тип сообщения — PHP Notice, далее описание проблемы — "Undefined index: foo" (в коде происходит обращение к неопределённому индексу массива), и указание на место ошибки — файл functions.php темы mytheme, строка 123.

Сообщения типа Notice — это некритичные уведомления, они не останавливают работу сайта, но указывают на недочёты в коде. Warning — более серьёзный сигнал, однако сайт продолжает функционировать. Fatal error — фатальная ошибка, которая приводит к остановке скрипта, страница может не загрузиться совсем. Просматривая лог, обращайте особое внимание на Fatal error. Такие записи требуют первоочерёдного исправления, поскольку напрямую влияют на работоспособность сайта.

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

После исправления проблемы не забудьте заглянуть в лог ещё раз. Старые записи журнала, которые уже утратили актуальность, можно удалить, чтобы файл не разрастался. Просто очистите содержимое debug.log или переименуйте (удалите) его, WordPress заново создаст файл при возникновении новых ошибок.

Плагины для работы с логами

Встроенный журнал debug.log значительно облегчает отладку, но просматривать его вручную бывает не слишком удобно. Существуют плагины, которые помогают работать с логами непосредственно из админ-панели WordPress.

Если вы хотите отслеживать технические ошибки прямо из админки, обратите внимание на плагин WP Log Viewer. Он добавляет в консоль администратора виджет, показывающий последние записи debug.log прямо на панели. Через WP Log Viewer можно включать и выключать запись лога одним нажатием, фильтровать ошибки по типам, очищать журнал и даже подсвечивать различные виды сообщений разными цветами для наглядности.

А плагин Error Log Monitor поможет не пропустить новые ошибки. Помимо виджета с отображением последних строк журнала он умеет отправлять уведомления на email, когда в лог пишется что-то новое. Вы можете задать интервал проверки и всегда быть в курсе, если на сайте произошёл свежий сбой, не заходя каждый раз в админку.

Помимо ошибок, которые фиксируются в debug.log, многих владельцев сайтов интересует журнал действий пользователей, кто и что делал в админке. WordPress не сохраняет такую информацию по умолчанию, но можно добавить подобный чёрный ящик с помощью плагинов. Среди популярных плагинов такого рода можно отметить Activity Log. Этот плагин записывает практически все действия. Другой схожий плагин, WP Security Audit Log, фокусируется на безопасности. Он отслеживает изменения на сайте, фиксирует добавление новых пользователей, изменения ролей и прочие потенциально важные события. Такие инструменты позволяют держать руку на пульсе активности сайта и при необходимости быстро обнаружить нежелательные изменения.

Указанные плагины ведут свои логи отдельно от системных и от debug.log. Зачастую они хранят информацию в базе данных сайта или в собственных файлах. Вы можете использовать их параллельно с основным журналом ошибок WordPress. В результате получите полную картину.

Заключение

Теперь, настроив отдельный журнал ошибок, вы фактически получили для своего сайта маленький чёрный ящик. Больше никакая скрытая ошибка не застанет вас врасплох. Вам достаточно открыть debug.log, и сразу станет ясно, что пошло не так. Регулярно проверяя логи, вы сможете предвидеть неполадки и поддерживать работу сайта настолько же стабильно, насколько уверенно пилот держит самолёт в небе.

Читайте в блоге:

Как настроить логи WordPress отдельно от системных логов