Безопасное логирование ошибок WordPress в production

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

Настройка `WP_DEBUG_DISPLAY` отвечает за показ сообщений PHP и WordPress в ответе страницы. Если она включена, на сайте могут появиться предупреждения, пути к файлам темы или плагинов, имена функций, фрагменты SQL и другие внутренние данные.

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

В production не следует использовать debug-режим как постоянный способ мониторинга. Его включают на ограниченное время, воспроизводят проблему, анализируют записи и возвращают безопасную конфигурацию.

• Не используйте `WP_DEBUG_DISPLAY` со значением `true` на публичном сайте.
• Не отправляйте пользователям полные stack trace и тексты SQL-ошибок.
• Не оставляйте подробное логирование включенным без контроля размера файла и доступа к нему.

Как включить логирование без вывода ошибок

Откройте `wp-config.php` и добавьте настройки перед строкой `That's all, stop editing! Happy publishing.` или ее локализованным аналогом. Важно не создавать дубликаты констант: если они уже есть в файле, измените существующие значения вместо добавления новых строк ниже.

Базовая конфигурация для временной диагностики выглядит так:

• `WP_DEBUG` включает режим диагностики WordPress.
• `WP_DEBUG_LOG` записывает сообщения в файл лога.
• `WP_DEBUG_DISPLAY` запрещает показ диагностических сообщений в браузере.
• `display_errors` дополнительно отключается на уровне PHP для текущего запроса.

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

Куда записывается лог

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

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

Как проверить проблему и прочитать debug.log

После сохранения `wp-config.php` воспроизведите ошибку тем же способом, которым ее видит пользователь: откройте нужную страницу, отправьте форму или выполните проблемное действие в админпанели. Затем проверьте, появилась ли новая запись в лог-файле.

Для просмотра последних строк на сервере Linux можно использовать:

• Ищите время события, имя файла, номер строки и компонент, вызвавший сообщение.
• Сравнивайте записи до и после конкретного действия, чтобы отделить актуальную ошибку от старых сообщений.
• Проверяйте не только `Fatal error`, но и `Warning`, `Notice`, `Deprecated`, а также сообщения об ошибках базы данных.
• Если файл не обновляется, проверьте фактический путь, права на запись и журналы PHP-FPM, веб-сервера или хостинга.

tail -f wp-content/debug.log

Что именно анализировать в записи

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

Не редактируйте код без резервной копии и не вносите непроверенные изменения в production, основываясь на одной строке лога. По возможности сначала воспроизведите проблему на staging-среде.

Как защитить файл с ошибками

Файл `wp-content/debug.log` часто находится в каталоге, доступном через веб-сервер. Если сервер отдает его по прямому URL, любой пользователь может скачать технические записи. В логах иногда оказываются email-адреса, идентификаторы пользователей, фрагменты SQL, токены или данные запросов.

Лучший вариант — хранить production-лог за пределами публичного web root, если это поддерживается вашей конфигурацией. Если файл должен оставаться в `wp-content`, ограничьте доступ на уровне веб-сервера и проверьте защиту отдельным запросом в приватном окне браузера.

• Для Apache используйте правило запрета доступа к конкретному файлу или каталогу в соответствии с конфигурацией сервера.
• Для Nginx добавьте отдельное правило `location`, которое запрещает доступ к `debug.log`.
• Не полагайтесь только на скрытие URL или нестандартное имя файла.
• Права файловой системы должны разрешать запись пользователю веб-сервера, но не делать файл доступным всем пользователям системы.
• После настройки проверьте доступ и по HTTP, и напрямую через SSH.

Ротация, размер и конфиденциальность логов

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

Во время анализа относитесь к логу как к конфиденциальным техническим данным. Не публикуйте его полностью в чатах или тикетах. Перед передачей разработчику удалите пароли, токены, cookie, email-адреса, IP-адреса и другие персональные данные.

Если в коде плагина или темы данные вручную записываются через `error_log()`, убедитесь, что в лог не попадают пароли, API-ключи, полные тела запросов или платежная информация. Логирование WordPress не делает такие данные безопасными автоматически.

• Определите максимальный размер файла и количество архивных копий.
• Ограничьте доступ к архивам так же, как и к текущему логу.
• Удаляйте старые копии в соответствии с внутренней политикой хранения данных.
• Следите за свободным местом на диске после включения диагностики.

Как отключить debug-режим после диагностики

Когда причина ошибки найдена и проверена, верните production-конфигурацию. Обычно это означает отключение всех четырех настроек или удаление временных строк из `wp-config.php`.

• Убедитесь, что `WP_DEBUG` имеет значение `false`.
• Отключите `WP_DEBUG_LOG`, если постоянное логирование не требуется вашей системе мониторинга.
• Оставьте `WP_DEBUG_DISPLAY` отключенным в production.
• Проверьте сайт в браузере и просмотрите журналы PHP или веб-сервера после изменения.
• Безопасно удалите или заархивируйте старый `debug.log`, если он больше не нужен.

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

Если ошибка нужна для долгосрочного мониторинга

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

Если production-среда поддерживает переменные окружения или отдельную конфигурацию для staging, храните диагностические настройки за пределами репозитория и не переносите их случайно на рабочий сайт.