Как собрать пригодный для исправления протокол ошибки WordPress: слой журнала, точное время, корреляция запроса, закрытая отладка, безопасный фрагмент и повторная приёмка.
Какие журналы бывают
| Журнал | Что искать |
|---|---|
| Access log | Маршрут, HTTP-статус, время, идентификатор |
| Веб-сервер error log | Проблемы связи и обработки |
| PHP | Ошибки и предупреждения выполнения |
| Приложение/плагин | Бизнес-событие и внешний ответ |
| Cron/очередь | Статус фонового задания |
| Внешний сервис | Связанный идентификатор операции |
Зафиксируйте событие
Запишите URL, действие, пользователя/роль без лишних персональных данных и время с часовым поясом. Если ошибка появляется после обновления, укажите компонент и версию. Для периодического сбоя сохраните несколько случаев, чтобы отличить закономерность от случайного совпадения.
Используйте request ID или другой безопасный идентификатор для связи журналов. Один и тот же час в разных часовых поясах может привести к неверному выводу. Уточните формат времени на сервере и в приложении.
Составьте воспроизводимый пример до включения подробного лога
Выберите одно действие с понятным ожиданием. Для медиа это загрузка конкретного обезличенного файла и создание размеров; для формы — тестовое сообщение согласованному получателю; для редактора — сохранение черновика. Укажите версию компонента, роль и состояние входа. Если ошибка появляется только после нескольких шагов, сохраните всю последовательность, а не последний клик.
Не повторяйте записывающую операцию вслепую после ошибки ответа. Прочитайте фактическое состояние и проверьте внешний результат. Дублированный заказ или отправленное дважды письмо не становятся безопаснее от того, что вы собирали журнал. Для диагностики используйте стенд и тестовые интеграции, когда это позволяет воспроизвести проблему без рабочих последствий.
Сценарий: загрузить тестовое изображение
Окружение: версии и контекст
Ожидание: файл и производные размеры доступны
Факт: точное сообщение или HTTP-статус
Время: дата / часовой пояс
Request ID: если предусмотрен
Состояние после: сохранено / не сохранено / неизвестноОтладка на стенде
В WordPress существуют WP_DEBUG, WP_DEBUG_LOG и WP_DEBUG_DISPLAY. Их поведение и расположение файла задаются конфигурацией. Не показывайте диагностические сообщения посетителям. Для лога выбирайте закрытое место и контролируйте доступ и срок хранения.
Включение журнала само по себе не исправляет ошибку. Повторите конкретное действие, затем прочитайте соответствующий фрагмент. Не оставляйте подробную диагностику бессрочно, особенно если она быстро заполняет диск или сохраняет аргументы запросов.
Разделите запись ошибок и показ посетителю
Подробный вывод в браузер способен раскрыть путь, структуру кода и данные. Запись в закрытый журнал и отображение посетителю — разные настройки. На стенде выберите документированный режим WordPress и конфигурацию PHP, не дублируя уже заданные константы. Место хранения должно быть действительно закрыто от публичного HTTP-доступа, а не просто иметь непривычное имя.
Не вставляйте универсальный путь из примера в рабочий wp-config.php. Реальный путь, владелец файла и доступность записи зависят от площадки. На shared используйте предусмотренный журнал панели или согласованный закрытый каталог. На VPS администратор проверяет права и ротацию. Невозможность записи может дать пустой лог, который ошибочно принимают за отсутствие ошибок.
| Проверка | Зачем нужна |
|---|---|
| Режим записи | Сообщения действительно сохраняются |
| Публичное отображение | Посетитель не получает диагностику |
| Закрытый путь | Журнал не скачивается как файл сайта |
| Права | Приложение может писать без лишнего доступа |
| Срок и ротация | Отладка не заполняет диск бессрочно |
| Контрольное действие | Известно, что наблюдается нужный запрос |
Как читать сообщение
Различайте фатальную ошибку, предупреждение и устаревающий вызов. Имя файла в трассировке помогает найти компонент, но не всегда является первопричиной: он может получать неправильные данные от другого расширения. Сопоставьте сообщение с изменениями и шагом воспроизведения.
Пример: ошибка только при создании миниатюры требует проверки изображения, расширения PHP и памяти. Ошибка только при ответе API — статуса и формата внешнего ответа. Не переключайте версию PHP, права и кэш одновременно без основания.
Читайте последовательность, а не последнюю строку
Фатальная ошибка может вызвать последующие предупреждения и отказ шлюза. Начните с первого значимого события в нужном временном интервале и сопоставьте его с действием. Имя сторонней библиотеки в трассировке показывает место обнаружения, но неверный аргумент мог прийти из другого компонента. Не обвиняйте разработчика по одному пути без воспроизведения.
Устаревающий вызов, предупреждение и остановка исполнения имеют разный эффект. Большой поток deprecated может мешать наблюдению и занимать диск, но удаление сообщений не исправляет код. Зафиксируйте отдельные типы, их частоту в проверенной области и влияние. Не повышайте память при ошибке отсутствующей функции: сначала проверьте версии и расширения, связанные с вызовом.
Синтетический пример разбора
Если учебная ошибка возникает только во время создания миниатюры, проверьте исходный файл, поддерживаемый формат, библиотеку обработки и ресурс именно этой операции. Если сбой только при внешнем API, смотрите соединение, код ответа и обработку формата. Это направления диагностики, а не установленные причины конкретного инцидента HOSTIO.
Свяжите несколько журналов
Сопоставьте время access log, сообщения веб-сервера, PHP и плагина. Часовой пояс и формат могут различаться. Если есть request ID или идентификатор фоновой задачи, используйте его, не подменяя временную связь простым совпадением минут. Для очереди сохраняйте hook и статус; для внешнего сервиса — разрешённый идентификатор события.
- Определите временной интервал и часовой пояс каждого источника.
- Найдите запрос по маршруту и безопасному идентификатору.
- Сверьте ответ шлюза с началом и завершением приложения.
- Найдите конкретное сообщение обработчика.
- Отделите подтверждённые факты от гипотез.
- После исправления повторите ту же цепочку наблюдения.
Пустой журнал может означать другой путь, отключённый сбор, неверные права или отсутствие запуска. Прежде чем делать вывод «ошибок нет», подтвердите сам канал наблюдения. Системные сообщения о завершении процесса могут находиться вне WordPress и требовать администратора площадки.
Что отправить поддержке
Передайте время, URL, ожидаемый и фактический результат, код ошибки и небольшой относящийся к событию фрагмент. Удалите токены, пароли, cookie, содержимое форм и персональные данные, если они не требуются для согласованной диагностики.
Скриншот «ошибка» без времени часто недостаточен. Полный архив всех журналов тоже не всегда нужен. Если поддержке требуется доступ, используйте разрешённый ограниченный способ, а не публикацию общего пароля.
Приёмка исправления
Повторите исходный сценарий и убедитесь, что результат корректен, а соответствующая ошибка больше не возникает. Затем проверьте соседние функции, которые могло затронуть изменение. Старые записи в журнале не исчезнут сами, поэтому ориентируйтесь на время нового теста.
Сохраните вывод и уберите временные режимы по плану. Если найден только обход, оставьте это в документации. Журнал должен помогать следующему ответственному, а не содержать неразобранный поток сведений.
Сохраните минимальный полезный фрагмент
Перед передачей уберите Authorization, cookies, пароли, токены, содержимое форм и ненужные персональные поля. Сохраняйте тип сообщения, компонент, версию, время и необходимую последовательность. Если обезличивание меняет важное условие, объясните это получателю и используйте согласованный закрытый канал. Полная публичная выгрузка логов не является нормальным способом получить помощь.
Для длительной диагностики назначьте владельца, срок и ограничение объёма. После завершения уберите временную подробность по плану, сохранив нужный протокол инцидента. Не удаляйте весь журнал автоматически после первого успеха: следующий штатный цикл может показать повтор. Приёмка должна учитывать и отсутствие новой ошибки, и правильность результата.
FAQ и рабочий отчёт
Пустой debug.log означает отсутствие ошибок?
Нет. Проверьте место записи, права, конфигурацию и запуск нужного запроса.
Файл плагина в трассировке доказывает его вину?
Он показывает место наблюдения. Причина может находиться в переданных данных или зависимости; нужна последовательность.
Можно ли оставить показ ошибок на рабочем сайте?
Посетителям не следует раскрывать диагностические сведения. Используйте закрытое журналирование по правилам среды.
Достаточно ли удалить старые строки после исправления?
Нет. Повторите исходный сценарий и проверяйте время нового теста, корректность данных и соседние функции.
Полезный отчёт содержит точное действие, ожидаемый и фактический результат, связанный фрагмент и подтверждение исправления. Технический журнал помогает принять решение, но не заменяет функциональную проверку.
Источники и дата
Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.
