Устранение «белого экрана смерти» в WordPress

«Белый экран смерти» в WordPress — это фатальная ошибка PHP при отключённом выводе ошибок: код аварийно завершился, не успев сформировать HTML, а WordPress скрывает текст ошибки, чтобы она не раскрывала посетителям пути к файлам и подробности о сервере.

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

Что такое «белый экран смерти» в WordPress?

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

Прежде чем что-либо предпринимать, проверьте почтовый ящик администратора. Начиная с версии 5.2 WordPress отправляет администратору письмо при возникновении фатальной ошибки, указывая сбойный плагин или тему и прилагая ссылку для входа в режим восстановления — состояние, в котором сломанный компонент приостановлен, так что вы можете попасть в панель управления и отключить его. Эта ссылка содержит секретный ключ; вручную набранный URL режима восстановления доступа не даст. Если письмо так и не пришло (спам-фильтры его съедают, а само письмо отправляется только тогда, когда ошибка возникает на защищённой точке входа, такой как wp-login.php или админка, а не на странице фронтенда или в задании cron), продолжайте читать далее.

Включите логирование, а не вывод на экран

Откройте wp-config.php через SFTP или файловый менеджер хостинга и добавьте эти строки выше /* That's all, stop editing! */:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Перезагрузите сломанную страницу, затем откройте лог — обычно он находится в wp-content/debug.log. Согласно документации по отладке WordPress, WP_DEBUG_LOG не действует, если WP_DEBUG не равен true, а WP_DEBUG_DISPLAY по умолчанию равен true — именно поэтому в приведённом фрагменте он явно выставлен в false. Никогда не выводите ошибки на страницу работающего сайта: каждый посетитель увидел бы пути на сервере и подробности кода. Удалите все четыре строки после того, как сайт будет исправлен.

Читаем ошибку: путь указывает на виновника

Лог даёт вам файл и номер строки, а каталог в этом пути говорит, какой компонент дал сбой. Реалистичная запись выглядит так:

PHP Fatal error: Uncaught Error: Call to undefined function acme_slider_init() in /home/example/public_html/wp-content/plugins/acme-slider/includes/display.php:87

Путь находится внутри wp-content/plugins/acme-slider/, значит причина — плагин Acme Slider, и переименование одной этой папки немедленно вернёт сайт к жизни. Общее правило:

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

Как исправить ошибку исчерпания памяти в WordPress?

Ошибка, начинающаяся с Allowed memory size of X bytes exhausted, означает, что PHP достиг предела памяти в середине обработки запроса. Увеличьте лимит WordPress в wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

По умолчанию WordPress задаёт WP_MEMORY_LIMIT равным 40M на одиночных сайтах и 64M в мультисайте, причём лимит PHP он только повышает и никогда не понижает. Константа работает лишь в пределах того потолка, который установлен вашим хостингом на уровне сервера; если 256M ничего не меняют, значит ограничение задано тарифным планом, а не настройкой, и повышать его придётся хостеру.

Как отключить проблемный плагин без доступа к wp-admin?

Если лог указывает на конкретный плагин, переименуйте только его папку внутри wp-content/plugins/. Если лог пуст, действуйте методом деления: переименуйте wp-content/plugins в plugins.hold, откройте /wp-admin/plugins.php, чтобы WordPress отметил отсутствующие плагины как деактивированные, верните папке исходное имя, а затем включайте плагины по одному, перезагружая сайт после каждого, пока он не сломается. Плата за этот путь — необходимость вручную включить все плагины обратно, зато сохранённые каждым из них настройки остаются нетронутыми.

Нет доступа к файлам, но есть phpMyAdmin? Откройте таблицу wp_options (ваш префикс может отличаться от wp_), найдите строку, где option_name равно active_plugins, и скопируйте или выгрузите её текущее значение option_value в надёжное место. Затем замените значение на сериализованный пустой массив a:0:{}, что деактивирует все плагины сразу. Позже вы сможете восстановить сохранённое значение, если понадобится исходный список.

Как отключить сломанную тему?

Если лог указывает внутрь wp-content/themes/, переименуйте только папку активной темы, например mytheme в mytheme.hold. WordPress переключится на встроенную стандартную тему, если она установлена; если нет — сначала установите её через файловый менеджер. Обычный виновник — functions.php, и лог уже сообщил вам точную строку, чаще всего это недавняя правка с синтаксической ошибкой. Исправьте эту строку и верните папке исходное имя.

Всё ещё пусто? Кеши, права доступа и версия PHP

Прежде чем доверять любому результату, очистите все кеши: кеш страниц плагина, любой серверный кеш и кеш браузера. Закешированная пустая страница может создать впечатление, что исправленный сайт всё ещё сломан, а закешированная рабочая страница может скрыть реальную ошибку. Затем проверьте права доступа к файлам — обычно это 755 для каталогов и 644 для файлов на виртуальном хостинге — и убедитесь в версии PHP: базовая версия, рекомендуемая WordPress, — 8.3 или новее. Сайт на 7.4 всё ещё будет загружаться, но эта ветка перестала получать исправления безопасности много лет назад.

Три случая выходят за рамки этой статьи: восстановление из бэкапа (инструмент резервного копирования вашего хостинга, с оговоркой, что вы потеряете всё, что появилось после снимка), повреждённые файлы ядра (скопируйте свежую загрузку WordPress поверх всего, кроме wp-content и wp-config.php) и вредоносный код (следуйте процедуре восстановления взломанного сайта, предлагаемой вашим хостингом).

Подведём итоги

Пустая страница WordPress — это подавленное сообщение об ошибке, а не загадка, и самый быстрый способ решения — всегда прочитать это сообщение, а не пытаться угадать причину. Добавьте четыре отладочные строки в wp-config.php прямо сейчас, перезагрузите страницу один раз, и путь в wp-content/debug.log точно скажет вам, какую папку переименовать.

Часто задаваемые вопросы

В чём разница между «белым экраном смерти» и сообщением «На этом сайте произошла критическая ошибка»?

Начиная с WordPress 5.2 встроенный обработчик фатальных ошибок перехватывает большинство фатальных ошибок PHP и выводит сообщение о критической ошибке вместо пустой страницы. Полностью белый экран означает, что PHP завершился до того, как этот обработчик успел сработать, — обычно из-за исчерпания памяти или ошибки на очень раннем этапе загрузки, например внутри wp-config.php. Оба случая вызваны фатальными ошибками PHP, и шаги отладки для них идентичны.

Почему wp-content/debug.log пуст, хотя WP_DEBUG включён?

Обычные причины — ошибка, возникающая до того, как отладочные константы вступают в силу (например, синтаксическая ошибка в самом wp-config.php), или каталог wp-content, недоступный веб-серверу для записи, из-за чего WordPress не может создать файл. Убедитесь, что константы расположены выше комментария о прекращении редактирования, а затем запросите у хостинга серверный лог ошибок PHP, который фиксирует фатальные ошибки независимо от настроек WordPress.

Почему белый экран появляется на некоторых страницах, но не на других?

Фатальная ошибка находится в коде, который выполняется только при этих запросах. Сбой в файле шаблона темы делает пустым фронтенд, тогда как wp-admin продолжает работать, потому что админка не отрисовывает шаблоны фронтенда. Сбой в коде плагина, работающем только в админке, даёт обратную картину. Включите логирование отладки, загрузите одну сломанную страницу, и путь к файлу в записанной ошибке укажет на сбойный компонент.

Безопасно ли оставлять WP_DEBUG и WP_DEBUG_LOG включёнными после исправления сайта?

Нет. По умолчанию лог пишется в wp-content/debug.log — предсказуемый путь, доступный из веба, который многие хостинги не блокируют, поэтому любой, кто запросит этот URL, сможет прочитать пути к файлам, детали ошибок и внутренности плагинов, а файл при этом растёт без ротации. Удалите отладочные строки из wp-config.php после того, как сайт заработает, либо задайте WP_DEBUG_LOG свой путь к файлу за пределами публичного веб-корня.