Ошибка WordPress может появляться раз в неделю, только при конкретном заказе или только во время фоновой задачи. Если журналирование не настроено, диагностика превращается в догадки и бесконечное отключение плагинов.
Я настраиваю логи WordPress и WooCommerce так, чтобы по конкретному времени и событию можно было увидеть, что произошло на сайте и где искать причину.
Когда стандартного сообщения об ошибке недостаточно
Белый экран, ошибка 500, зависший checkout или пропавшая синхронизация говорят только о результате. Причина может находиться в PHP, базе данных, внешнем API, cron, Action Scheduler, теме или отдельном плагине.
Хороший лог связывает ошибку со временем, запросом и компонентом. Тогда вместо проверки всего сайта можно разбирать конкретный участок.
Что я проверяю в WordPress
Сначала смотрю, какие журналы уже доступны на сервере и не записывают ли они лишние данные. Затем настраиваю безопасное журналирование для нужной задачи. Это могут быть PHP ошибки, WordPress debug log, nginx или Apache, WooCommerce, фоновые задания и собственные интеграции.
Логи не должны бесконтрольно расти и заполнять диск. Для рабочего сайта важны ротация, ограничение срока хранения и понятное разделение технических событий.
WooCommerce требует отдельного внимания
В интернет магазине недостаточно знать, что страница открывается. Ошибка может возникать только при оплате, создании заказа, изменении остатка или отправке данных во внешнюю систему.
Поэтому при диагностике WooCommerce я проверяю журналы самого магазина, фоновые задачи, webhooks и API интеграции. Если сбой связан с конкретным заказом, логирование должно позволять найти цепочку событий без изменения данных заказа.
Логи для API и автоматизаций
Интеграция может получить ошибку от CRM, склада, платёжного сервиса или поставщика. Без записи статуса запроса и безопасного контекста невозможно понять, запрос не ушёл, внешний сервис его отклонил или ответ не был обработан.
При этом секреты, токены, пароли и платёжные данные не должны попадать в журнал. Я отделяю полезную диагностическую информацию от чувствительных данных.
Почему нельзя постоянно держать подробный debug включённым
Подробный debug полезен во время диагностики, но на production его нужно использовать аккуратно. Большой поток сообщений создаёт лишнюю запись на диск, усложняет поиск нужного события и может случайно сохранить чувствительные данные.
Поэтому режим диагностики должен решать конкретную задачу. После исправления проблемы уровень журналирования возвращается к нормальному рабочему состоянию.
Что получает владелец сайта
После настройки становится понятно, где смотреть ошибки, какие события действительно важны и как быстро собрать данные при повторении проблемы. Если причина уже проявляется в логах, я могу сразу перейти к исправлению конкретного компонента.
Если WordPress или WooCommerce периодически выдаёт ошибки, зависает или теряет данные интеграции, отправьте описание проблемы через контакты. Проверю текущие журналы, настрою недостающее логирование и найду точку сбоя.
Обсуждение
Вопросы и комментарии
Можно уточнить детали статьи или поделиться своим опытом. Первый комментарий проходит проверку.