Ошибки WordPress: что проверить перед исправлением

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

Сначала зафиксируйте, как проявляется ошибка

Фраза «WordPress не работает» слишком общая для диагностики. Один посетитель может видеть белую страницу, другой — сообщение о критической ошибке, а администратор — сбой только при сохранении записи или оформлении заказа. Эти ситуации выглядят похоже, но проверяются по-разному.

Запишите точный адрес страницы, действие перед сбоем и примерное время с учётом часового пояса. Проверьте сайт в другом браузере и в приватном окне. Если проблема проявляется только у одного пользователя, отдельно уточните его роль, устройство и последовательность действий. Не публикуйте в скриншотах адреса панели управления, ключи, пароли и персональные данные.

Минимальный набор данных перед исправлением:

• точный URL, действие и время появления ошибки;
• скриншот или дословный текст сообщения без закрытых данных;
• список обновлений и изменений перед сбоем;
• дата последней проверенной резервной копии;
• фрагмент журнала за нужный момент без паролей и токенов.

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

Что подготовить до любых изменений

До обновления, отключения компонентов или редактирования файлов убедитесь, что можно вернуть сайт в рабочее состояние. Нужна резервная копия файлов и базы данных, а также понятный способ восстановления. Сам факт наличия архива недостаточен: уточните дату, состав копии и место хранения.

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

Заранее проверьте доступ в панель WordPress, кабинет хостинга, файловый менеджер или SFTP и систему резервных копий. Для диагностики базы данных может потребоваться доступ к панели хостинга, но передавать исполнителю главный пароль от всех сервисов не следует. Лучше создать отдельную учётную запись с необходимыми правами и удалить её после работ.

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

Проверьте последние обновления и изменения

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

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

Если в панели доступны сведения о версиях, сохраните их до изменений. Раздел Инструменты → Здоровье сайта → Информация показывает данные о WordPress, активной теме, плагинах, сервере, базе данных и правах файловой системы. Экспорт этого отчёта удобен для специалиста, но перед отправкой его всё равно нужно проверить на наличие закрытых данных.

Где искать техническую причину

Текст на экране описывает симптом, но не всегда называет источник. Для поиска причины сопоставляют время запроса с журналом PHP, журналом веб-сервера и журналами приложения. На управляемом хостинге эти данные могут находиться в панели; в других случаях их предоставляет техническая поддержка хостинга.

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

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

Как проверять плагины и тему безопасно

Плагины и тема действительно могут участвовать в сбое, но отключение всего набора на рабочем сайте — рискованный первый шаг. Оно способно изменить внешний вид, формы, оплату, обмен данными и фоновые процессы. Безопаснее воспроизвести проблему на тестовой копии и последовательно исключать компоненты.

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

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

Когда обращаться к хостингу или разработчику

В поддержку хостинга стоит обратиться, если недоступен сервер или база данных, изменились лимиты и версия PHP, закончились ресурсы, возникают ошибки файловой системы либо нужные журналы доступны только провайдеру. Передайте домен, точное время, URL, код ответа и идентификатор запроса, если он указан.

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

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

Главное: до исправления сохраните исходное состояние, подготовьте восстановление и соберите доказательства. Последовательная проверка одной гипотезы за раз безопаснее случайных правок и помогает отличить причину ошибки WordPress от её внешнего проявления.