Как создать и получить доступ к журналам ошибок для WordPress (3 метода)

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

В этом руководстве рассматриваются три проверенных в production-среде метода включения, поиска и чтения журналов ошибок WordPress: встроенный стек WP_DEBUG, журналы на уровне сервера через панель управления хостингом и плагины для просмотра журналов. Каждый метод подходит для определённого уровня доступа и варианта использования, и все три описаны с точными путями к файлам, синтаксисом конфигурации и соображениями безопасности.

Почему журналы ошибок WordPress важны

WordPress работает на PHP, который генерирует несколько классов сообщений времени выполнения: фатальные ошибки (выполнение останавливается), предупреждения (выполнение продолжается, но что-то не так), уведомления (информационные, часто указывающие на устаревший код) и сообщения об устаревших функциях (функции, запланированные к удалению). По умолчанию ни одно из них не записывается в постоянный журнал в большинстве production-конфигураций — они либо подавляются, либо выводятся в браузер, что является угрозой безопасности.

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

Метод 1: Включение режима отладки WordPress через wp-config.php

WordPress поставляется со встроенной подсистемой отладки, управляемой набором PHP-констант, определённых в wp-config.php. Это наиболее точный метод, поскольку он перехватывает специфичные для WordPress ошибки, включая те, что генерируются API плагинов, загрузчиком тем и уровнем абстракции базы данных (wpdb).

Шаг 1: Найдите и откройте wp-config.php

Подключитесь к серверу через SFTP (предпочтительнее обычного FTP по соображениям безопасности) с помощью клиента FileZilla или Cyberduck, либо откройте файловый менеджер вашего хостинг-провайдера. Перейдите в корневой каталог WordPress, обычно это /public_html/ или /var/www/html/. Файл wp-config.php находится в корне этого каталога.

При наличии SSH-доступа его можно редактировать напрямую:

nano /var/www/html/wp-config.php

Шаг 2: Настройте константы отладки

Найдите существующую строку:

define( 'WP_DEBUG', false );

Замените весь блок следующей конфигурацией, которая включает ведение журнала без отображения ошибок посетителям сайта:

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

Что делает каждая константа:

• WP_DEBUG — активирует движок отладки WordPress и включает отчёты об ошибках PHP на уровне E_ALL.
• WP_DEBUG_LOG — записывает все перехваченные ошибки в файл журнала вместо вывода на экран (или в дополнение к нему).
• WP_DEBUG_DISPLAY — при значении false подавляет вывод на экран. Это критически важно для production-сайтов: без этой настройки PHP-уведомления раскрывают посетителям внутренние пути к файлам и имена переменных.
• display_errors — базовая директива PHP; установка значения 0 через ini_set обеспечивает второй уровень подавления на случай, если плагин или тема переопределяет WP_DEBUG_DISPLAY.

Шаг 3: Найдите файл журнала отладки

При значении WP_DEBUG_LOG равном true WordPress записывает ошибки в:

/wp-content/debug.log

Этот файл создаётся автоматически при первой записанной ошибке. Его можно просматривать через SFTP или SSH:

tail -f /var/www/html/wp-content/debug.log

Флаг tail -f выводит новые записи в реальном времени, что незаменимо при интерактивном воспроизведении конкретной ошибки.

Шаг 4: Используйте пользовательский путь к журналу (рекомендуется из соображений безопасности)

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

Вариант A — Переместите файл журнала за пределы корневого каталога веб-сервера:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/debug.log' );

Создайте целевой каталог и установите права доступа:

mkdir -p /var/log/wordpress
chown www-data:www-data /var/log/wordpress
chmod 750 /var/log/wordpress

Вариант B — Заблокируйте путь по умолчанию через .htaccess (Apache):

<Files "debug.log">
    Order allow,deny
    Deny from all
</Files>

Вариант C — Эквивалент для Nginx в блоке сервера:

location ~* /wp-content/debug.log {
    deny all;
    return 404;
}

Шаг 5: Отключите режим отладки после устранения неполадок

Никогда не оставляйте WP_DEBUG со значением true на работающем сайте дольше, чем необходимо. После решения проблемы:

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', false );

Оставление режима отладки активным на production-сайте снижает производительность (PHP обрабатывает каждое уведомление E_ALL) и может раскрыть конфиденциальные трассировки стека, если WP_DEBUG_DISPLAY случайно установлено в true.

Метод 2: Доступ к журналам ошибок на уровне сервера через панель управления хостингом

Ошибки WordPress, возникающие до завершения загрузки WordPress, — например, повреждённый wp-config.php, несовместимость версий PHP или сбой подключения к базе данных — никогда не появятся в debug.log, поскольку сам WordPress так и не загружается. Для их диагностики необходим журнал ошибок PHP или журнал ошибок Apache/Nginx на уровне сервера.

Хостинг на базе cPanel

Если ваша хостинговая среда использует VPS с cPanel, журнал ошибок доступен через интерфейс панели управления:

1. Войдите в cPanel.
2. Перейдите в раздел Метрики > Ошибки.
3. Панель отображает последние 300 строк журнала ошибок Apache для вашего аккаунта.

Для получения полного файла журнала используйте Файловый менеджер cPanel или подключитесь через SFTP и перейдите по пути:

/home/yourusername/logs/yourdomain.com-ssl_log
/home/yourusername/logs/yourdomain.com-error_log

Точные имена файлов зависят от конфигурации сервера, но шаблон одинаков для большинства установок cPanel.

Хостинг на базе Plesk

В Plesk перейдите в раздел Сайты и домены > выберите домен > Журналы. Вы можете фильтровать по типу журнала (доступ, ошибки, PHP) и скачать полный файл журнала.

Прямой доступ к серверу (VPS или выделенный сервер)

В среде VPS-хостинга или выделенного сервера с root-доступом расположение журналов зависит от используемого стека:

Для мониторинга журнала PHP-FPM в реальном времени:

tail -f /var/log/php8.2-fpm.log

Для поиска фатальных ошибок WordPress в журнале Apache:

grep -i "fatal|wordpress|wp-" /var/log/apache2/error.log | tail -50

Настройка логирования ошибок PHP на уровне сервера

Если ошибки PHP не записываются в журнал, проверьте конфигурацию php.ini:

php --ini | grep "Loaded Configuration"

Откройте найденный файл php.ini и проверьте или установите следующие параметры:

log_errors = On
error_log = /var/log/php_errors.log
display_errors = Off
error_reporting = E_ALL

Перезапустите PHP-FPM после внесения изменений:

systemctl restart php8.2-fpm

Либо переопределите настройки PHP для конкретного сайта с помощью файла .htaccess (только для Apache):

php_flag log_errors on
php_value error_log /var/log/wordpress/php_errors.log
php_flag display_errors off

Метод 3: Использование плагина для логирования ошибок WordPress

Для сред с ограниченным прямым доступом к серверу — например, при использовании виртуального хостинга — или для команд, где нетехнические администраторы должны просматривать ошибки без SSH-доступа, плагин WordPress является жизнеспособной альтернативой.

Рекомендуемые плагины

• WP Log Viewer — читает существующий файл debug.log и отображает его в административной панели WordPress с возможностью фильтрации и поиска.
• Error Log Monitor — добавляет виджет на панель управления с последними ошибками и может отправлять уведомления по электронной почте при появлении новых ошибок.
• Query Monitor — выходит за рамки логирования ошибок и позволяет профилировать запросы к базе данных, вызовы HTTP API, хуки и условные теги. Незаменим для отладки производительности.
• Health Check & Troubleshooting — официальный плагин WordPress.org; включает режим устранения неполадок, который активирует тему по умолчанию и отключает все плагины только для вашей сессии, не затрагивая других посетителей.

Установка и настройка Error Log Monitor

1. В административной панели WordPress перейдите в раздел Плагины > Добавить новый.
2. Найдите Error Log Monitor и нажмите Установить, затем Активировать.
3. Перейдите в раздел Настройки > Error Log Monitor.
4. Укажите путь к файлу журнала. Если вы переместили debug.log за пределы корневого каталога веб-сервера, введите здесь абсолютный путь на сервере.
5. Настройте частоту уведомлений по электронной почте, если хотите получать оповещения о новых типах ошибок.

Плагин читает тот же файл debug.log, в который записывает WP_DEBUG_LOG. Он не создаёт отдельный механизм логирования — это только просмотрщик. Это означает, что WP_DEBUG и WP_DEBUG_LOG по-прежнему должны быть включены в wp-config.php, чтобы плагин что-либо отображал.

Критическое ограничение: Плагины загружаются после запуска WordPress. Любая ошибка, препятствующая загрузке WordPress (сбой подключения к базе данных, повреждённый файл ядра, несовместимая версия PHP), не будет видна ни в одном плагине для просмотра журналов. В таких сценариях единственным вариантом остаётся Метод 2.

Сравнение: три метода логирования ошибок WordPress

Чтение и интерпретация записей журнала ошибок WordPress

Необработанная запись debug.log выглядит следующим образом:

[04-Jul-2025 14:32:11 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_field() in /var/www/html/wp-content/themes/mytheme/functions.php:47
Stack trace:
#0 /var/www/html/wp-content/themes/mytheme/functions.php(47): get_field()
#1 {main}
thrown in /var/www/html/wp-content/themes/mytheme/functions.php on line 47

Как читать эту запись:

• Временная метка указана в UTC — при необходимости переведите в местный часовой пояс сервера.
• PHP Fatal error означает, что выполнение было прервано. Страница, вызвавшая эту ошибку, вернула ошибку 500 или пустой экран.
• Call to undefined function get_field() означает, что плагин Advanced Custom Fields либо деактивирован, либо загружается после того, как functions.php темы попытался его вызвать.
• Трассировка стека показывает точный файл и номер строки. Начните отладку со строки 47 файла functions.php.

Распространённые шаблоны ошибок и их причины:

• PHP Warning: require(): Failed opening required — путь к файлу неверен или файл отсутствует. Часто вызывается плагином, ссылающимся на удалённый файл.
• PHP Deprecated: Function _register_controls is deprecated — плагин или тема использует устаревший API. Не фатально, но указывает на плагин, не обновлённый для текущей версии WordPress/Elementor.
• WordPress database error ... for query — запрос wpdb завершился ошибкой. Проверьте несоответствие префиксов таблиц или повреждённые таблицы.
• Maximum execution time of 30 seconds exceeded — скрипт выполнялся слишком долго. Характерно для крупных импортов, неоптимизированных запросов или вызовов внешних API с истечением времени ожидания.
• Allowed memory size of X bytes exhausted — PHP достиг лимита памяти. Увеличьте memory_limit в php.ini или определите плагин с утечкой памяти.

Лучшие практики управления журналами ошибок WordPress

Выполняйте ротацию журналов для предотвращения исчерпания дискового пространства. Нагруженный WordPress-сайт, подвергающийся атаке или имеющий повторяющуюся ошибку, может генерировать сотни мегабайт данных журнала в день. На Linux-серверах настройте logrotate:

nano /etc/logrotate.d/wordpress-debug

/var/log/wordpress/debug.log {
    daily
    rotate 14
    compress
    missingok
    notifempty
    create 640 www-data www-data
}

Никогда не добавляйте debug.log в систему контроля версий. Добавьте его в .gitignore:

wp-content/debug.log

Проверяйте wp-config.php после каждой миграции сервера. Миграции хостинга нередко сбрасывают WP_DEBUG до false или вводят новый шаблон wp-config.php, перезаписывающий ваши константы.

Используйте SAVEQUERIES для отладки на уровне базы данных. Добавьте эту константу вместе с WP_DEBUG для логирования каждого SQL-запроса, выполняемого WordPress:

define( 'SAVEQUERIES', true );

Затем проверьте $wpdb->queries в пользовательском шаблоне или через Query Monitor. Отключите его сразу после использования — он хранит каждый запрос в памяти и значительно увеличивает потребление RAM.

Сопоставляйте временные метки журналов с событиями развёртывания. Если появляется новый тип ошибки, проверьте, совпадает ли он с обновлением плагина, обновлением ядра WordPress или изменением версии PHP на сервере. Большинство панелей управления хостингом фиксируют изменения версии PHP в отдельном журнале аудита.

Матрица решений: какой метод использовать

Технический контрольный список ключевых выводов

• Установите WP_DEBUG_DISPLAY в false перед включением WP_DEBUG_LOG на любом сайте с живым трафиком.
• Переместите debug.log за пределы корневого каталога веб-сервера или заблокируйте его через правила сервера — путь по умолчанию общедоступен.
• Используйте tail -f для файла журнала при интерактивном воспроизведении ошибок — это избавляет от необходимости вручную обновлять файл.
• Журналы PHP и Apache/Nginx на уровне сервера — единственный достоверный источник информации об ошибках, возникающих до загрузки WordPress.
• Плагины для просмотра журналов требуют активного WP_DEBUG_LOG — они являются читателями, а не писателями.
• Реализуйте ротацию журналов на любом сервере, где WP_DEBUG_LOG включён более нескольких часов.
• Никогда не оставляйте SAVEQUERIES включённым в production — это нагрузка на память и производительность.
• После решения проблемы установите все константы отладки обратно в false и убедитесь с помощью браузерного запроса, что в исходном коде страницы не появляются PHP-уведомления.

—

Часто задаваемые вопросы

Где по умолчанию находится файл журнала отладки WordPress?

WordPress записывает журнал отладки в /wp-content/debug.log относительно корневого каталога WordPress. Этот путь создаётся только после записи первой ошибки и только при условии, что и WP_DEBUG, и WP_DEBUG_LOG установлены в true в файле wp-config.php. Вы можете переопределить путь, передав абсолютный путь к файлу в качестве значения WP_DEBUG_LOG вместо true.

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

Это безопасно только при условии, что WP_DEBUG_DISPLAY явно установлено в false, а display_errors установлено в 0. Без этих двух настроек ошибки PHP — включая внутренние пути к файлам и имена таблиц базы данных — отображаются непосредственно в HTML-коде каждой страницы. Всегда используйте WP_DEBUG true совместно с WP_DEBUG_DISPLAY false на любом сайте с публичным трафиком.

Почему файл debug.log пуст, хотя WP_DEBUG включён?

Наиболее распространённые причины: процесс веб-сервера не имеет прав на запись в каталог /wp-content/; WP_DEBUG_LOG установлено в false или отсутствует в wp-config.php; либо ошибка возникает на уровне сервера до загрузки WordPress, а значит, она появится в журнале Apache или PHP-FPM, а не в debug.log. Проверьте права доступа к каталогу с помощью ls -la wp-content/ и убедитесь, что константы определены в правильном порядке в wp-config.php.

В чём разница между WP_DEBUG_LOG и журналом ошибок PHP на сервере?

WP_DEBUG_LOG — это константа уровня WordPress, которая направляет ошибки, перехваченные пользовательским обработчиком ошибок WordPress, в debug.log. Журнал ошибок PHP на сервере (настраиваемый через error_log в php.ini) перехватывает все ошибки PHP на уровне интерпретатора, включая те, что возникают до инициализации WordPress. На правильно настроенном сервере оба журнала активны одновременно и дополняют друг друга.

Можно ли включить логирование ошибок на виртуальном хостинге без SSH-доступа?

Да. Вы можете редактировать wp-config.php через файловый менеджер вашего хостинг-провайдера в cPanel или Plesk, включить WP_DEBUG и WP_DEBUG_LOG, а затем читать debug.log через тот же интерфейс файлового менеджера. Для журналов на уровне сервера при использовании виртуального хостинга используйте раздел Ошибки в разделе Метрики cPanel. Если вам нужен более детальный контроль над конфигурацией PHP и путями к журналам, переход на тариф VPS-хостинга предоставит прямой доступ к php.ini и полный SSH-доступ ко всем файлам журналов.