Закрыть

 

White Screen of Death в WordPress — реальные причины и способы восстановления

Фото: White Screen of Death в WordPress — реальные причины и способы восстановления

Открывая админку или сайт на WordPress, вы можете столкнуться с пугающей ситуацией: вместо привычного интерфейса или содержимого страницы – лишь чистый белый экран. Эта проблема, известная как «White Screen of Death» (WSoD), полностью блокирует доступ к управлению или отображению ресурса. Она сигнализирует о критическом сбое в работе движка, плагинов или темы, требующем немедленного вмешательства.

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

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

Проверка поврежденных плагинов и тем

Неисправные файлы плагинов или тем часто провоцируют критический сбой. Стандартное отключение компонентов через админ-панель невозможно при белом экране. Требуется ручная проверка целостности файлов.

Получите доступ к сайту через FTP или файловый менеджер хостинга. Перейдите в каталог wp-content/plugins. Переименуйте папку каждого плагина по очереди (например, измените «plugin-name» на «plugin-name_off»). После каждого изменения проверяйте работоспособность сайта. Если белый экран исчезает – последний отключенный плагин проблемный.

Если плагины не виноваты, исследуйте активную тему. В папке wp-content/themes переименуйте директорию текущей темы. WordPress автоматически переключится на стандартную тему (например, Twenty Twenty-Four). Возвращение сайта подтверждает повреждение вашей темы.

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

После восстановления файлов верните оригинальные имена папкам плагинов и темы. Проверьте функциональность сайта. Если белый экран не возвращается – повреждение устранено.

Восстановление через файловый доступ (FTP/менеджер хостинга)

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

Первый шаг: Получите доступ к файлам сайта. Используйте данные FTP-аккаунта (логин, пароль, сервер) в программе типа FileZilla или войдите в панель управления хостингом и откройте встроенный файловый менеджер. Найдите корневую папку WordPress (часто public_html, www или с именем домена).

Переименование проблемных компонентов: Перейдите в папку wp-content. Здесь сосредоточена активная часть сайта:

1. Переименуйте папку plugins (например, в plugins.old). Это мгновенно деактивирует все плагины. Проверьте сайт. Если белый экран исчез, проблема в одном из плагинов. Восстановите исходное имя папки и поочередно переименовывайте подпапки внутри plugins, проверяя сайт после каждого изменения.

2. Если проблема осталась, аналогично поступите с текущей темой. Перейдите в wp-content/themes. Найдите папку активной темы и переименуйте её (например, добавив .backup). WordPress автоматически переключится на стандартную тему (Twenty Twenty-*). Проверьте сайт.

Проверка файла wp-config.php: Иногда ошибки в этом основном файле конфигурации вызывают белый экран. Найдите wp-config.php в корне сайта. Скачайте его копию на компьютер для безопасности. Откройте файл для редактирования через FTP/менеджер. Проверьте строки подключения к базе данных (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST) – убедитесь, что данные совпадают с данными из панели хостинга. Ищите лишние пробелы, отсутствие точек с запятой или кавычек.

Восстановление ядра WordPress: Если предыдущие шаги не помогли, возможны повреждения системных файлов. В корне сайта найдите папки wp-admin и wp-includes. Скачайте чистую версию WordPress с официального сайта, соответствующую вашей версии. Загрузите из скачанного архива папки wp-admin и wp-includes поверх существующих на сервере. Это заменит основные файлы, не затрагивая содержимое wp-content (темы, плагины, медиафайлы).

Проверка прав доступа: Неправильные права на файлы могут блокировать работу. Убедитесь, что для папок установлены права 755, для файлов – 644. Особенно проверьте wp-config.php (рекомендуется 600 или 644). Изменяйте права осторожно.

Логи ошибок: Если белый экран сохраняется, найдите файл журнала ошибок. Часто он называется error_log и находится в корне сайта или в папке wp-content. Откройте его и изучите последние записи – там могут быть указаны конкретные файлы и строки кода с ошибкой.

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

Анализ логов ошибок сервера и PHP

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

Найдите файлы логов через панель управления хостингом. Распространённые названия: error_log, php_error.log, или файлы в папках /logs/, /var/log/. Часто лог располагается в корне сайта или директории wp-content. Если доступ к панели отсутствует, обратитесь в службу поддержки хостинга.

Откройте файл лога текстовым редактором. Ищите записи с меткой «Fatal error», «Parse error» или «Out of memory», соответствующие времени появления проблемы. Ошибка синтаксиса в файле покажет путь к проблемному скрипту. Сообщение о превышении лимита памяти указывает на необходимость увеличения значения memory_limit в php.ini.

Пример критической ошибки:

[Tue Jan 01 12:00:00] PHP Fatal error: Cannot redeclare class_name() in /путь/к/файлу.php on line 50

Такая запись означает конфликт имён функций или классов между компонентами.

Если доступ к логам невозможен, временно включите отладку WordPress. Добавьте в wp-config.php строки:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

После обновления файла ошибки начнут записываться в wp-content/debug.log. Не оставляйте режим отладки включённым после решения проблемы.

Регулярная проверка логов помогает выявлять скрытые проблемы до их перерастания в критическую неисправность. Сохраняйте резервные копии логов перед внесением изменений на сайте для сравнения состояния.