Белый экран WordPress: что проверить до переустановки

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

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

Два вопроса владельцу до любых изменений

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

Второй вопрос: что изменилось перед первым замеченным сбоем? Это могло быть обновление, настройка, перенос или изменение среды хостинга. Зафиксируйте известные события со временем и источником информации. Совпадение по времени ещё не доказывает причину, но помогает выбрать первую проверку. Если сотрудник ничего не менял, это не исключает автоматического обновления или действия другого участника. Сведения нужно уточнить, а неизвестные оставить неизвестными.

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

Сохраните состояние, из которого можно продолжить разбор

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

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

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

Ошибку ищут рядом с воспроизведённой попыткой

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

В документации WordPress по отладке описаны отдельные настройки WP_DEBUG, WP_DEBUG_LOG и WP_DEBUG_DISPLAY. Сбор диагностической информации и показ ошибок посетителям различаются. Руководство рекомендует инструменты отладки для тестовых сред; перед изменениями следует иметь подходящую копию. В рамках этой статьи не предлагается включать подробные сообщения всем посетителям рабочего сайта. Место хранения и доступ к журналу также проверяют отдельно.

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

Проверка темы и плагинов — управляемый эксперимент

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

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

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

Восстановить доступность и исправить причину можно разными этапами

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

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

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

Приёмка должна включать действие, на котором сайт ломался

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

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

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