Белый экран и «критическая ошибка» в WordPress

Начиная с версии 5.2 WordPress вместо пустого белого экрана показывает сообщение «На сайте возникла критическая ошибка» и отправляет администратору письмо со ссылкой на режим восстановления. Суть та же: PHP упал с фатальной ошибкой. Хорошая новость — в 90% случаев сайт возвращается за 10–15 минут, если действовать по порядку.

Шаг 0. Проверьте почту администратора

WordPress отправляет на адрес администратора (Настройки — Общие) письмо с темой «На вашем сайте возникла техническая проблема». В нём указано, какой плагин или тема вызвали ошибку, и есть ссылка вида /wp-login.php?action=entered_recovery_mode. По этой ссылке вы входите в админку в режиме восстановления, где проблемный плагин временно отключён только для вас. Отключите его, и сайт заработает для всех.

Письмо часто не приходит — потому что на сайте не настроена почта. Об этом в статье «Не приходят заявки с сайта». Тогда переходим к следующим шагам.

Шаг 1. Включите журнал ошибок

Подключитесь к сайту по FTP или через файловый менеджер хостинга, откройте wp-config.php и найдите строку define( ‘WP_DEBUG’, false );. Замените её на:

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

Обновите страницу сайта и откройте файл /wp-content/debug.log. Ищите строку PHP Fatal error. В ней указан путь к файлу — по нему видно, кто виноват:

PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /wp-content/plugins/some-gallery/inc/front.php:87

Здесь виноват плагин some-gallery.

После того как сайт заработает, верните WP_DEBUG в false и удалите debug.log — он может быть доступен по прямой ссылке и раскрывать пути на сервере.

9 частых причин

1. Обновление плагина

Плагин обновился и стал несовместим с другим плагином, темой или версией PHP. Решение: отключить его (см. ниже), откатить на предыдущую версию — старые версии есть на странице плагина на wordpress.org во вкладке «Разработка» — «Дополнительно».

2. Обновление PHP на хостинге

Старые плагины и темы падают на PHP 8.0–8.3 из-за удалённых функций (create_function, each) и более строгой типизации. Быстрое решение — временно вернуть предыдущую версию PHP в панели хостинга. Правильное — обновить или заменить устаревшие компоненты.

3. Обновление WordPress

Ядро обновилось, а тема использует удалённые функции. Чаще всего это касается тем, купленных 5+ лет назад и не обновлявшихся.

4. Нехватка памяти

В логе: Allowed memory size exhausted. Добавьте в wp-config.php:

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

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

5. Ошибка в functions.php

Кто-то добавил код в functions.php темы через «Внешний вид — Редактор» и ошибся с точкой с запятой или скобкой. Сайт падает сразу. Откройте файл по FTP, уберите добавленный фрагмент. Чтобы этого не повторилось, отключите редактор файлов в wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

6. Повреждённые файлы ядра

Обновление прервалось на середине — часть файлов новая, часть старая. В корне сайта может остаться файл .maintenance, из-за которого сайт показывает «Сайт недоступен из-за планового обслуживания». Удалите .maintenance и перезалейте папки wp-admin и wp-includes из архива той же версии WordPress.

7. Конфликт плагинов кэширования

После включения кэширования или минификации JavaScript сайт показывает белую страницу или ломается вёрстка. Удалите папку /wp-content/cache и файлы advanced-cache.php и object-cache.php в /wp-content, если плагин кэша отключён.

8. Взлом

Вредоносный код в index.php, wp-config.php или в файлах плагинов, который ломает сайт. Признаки: длинные строки с eval, base64_decode, gzinflate в начале файлов. Тут нужен не откат, а полноценное лечение — см. статью «Вирус на сайте».

9. Закончилось место на диске

WordPress не может записать сессии и кэш. Проверьте квоту в панели хостинга.

Как отключить плагин без доступа к админке

Все плагины сразу. Переименуйте папку /wp-content/plugins в plugins_off. WordPress не найдёт плагины и деактивирует их. Зайдите в админку, верните имя папки — плагины окажутся отключёнными, включайте по одному.

Один плагин. Переименуйте его папку, например /wp-content/plugins/some-gallery в some-gallery_off.

Через WP-CLI, если есть SSH:

wp plugin deactivate some-gallery
wp plugin list --status=active

Через базу данных — в крайнем случае. В таблице wp_options в строке active_plugins хранится сериализованный массив. Замена значения на a:0:{} отключит все плагины.

Как переключить тему без админки

Переименуйте папку активной темы. WordPress переключится на одну из стандартных тем (Twenty Twenty-Four и подобные), если она установлена. Если стандартных тем нет — загрузите любую из них по FTP в /wp-content/themes.

Через WP-CLI:

wp theme activate twentytwentyfour

Если ошибка только в админке

Сайт открывается, а /wp-admin показывает критическую ошибку — виноват плагин, который подключает свой код только в админке, или плагин безопасности. Действуйте так же: журнал ошибок, отключение по одному. Если не получается войти вообще, смотрите статью «Не входит в админку WordPress».

Как не допустить повторения

• Обновляйте плагины не все разом, а по одному, и проверяйте сайт после каждого крупного обновления.
• Перед обновлением WordPress, WooCommerce и конструктора делайте резервную копию.
• Удалите плагины, которыми не пользуетесь, и темы, кроме активной и одной стандартной.
• Настройте почту, чтобы письма о критических ошибках доходили.
• Держите PHP актуальным, но меняйте версию осознанно, после проверки на копии.

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

Когда лучше не трогать самому

Если в debug.log пусто, ошибка в файлах ядра или вы видите признаки взлома — остановитесь и сделайте копию текущего состояния. Дальше можно написать мне: в рамках ремонта сайта я нахожу причину, возвращаю сайт и объясняю, что произошло.

Типичный разбор по шагам

Типичная ситуация: сайт на WordPress показывает «На сайте возникла критическая ошибка», письма о восстановлении не приходят. Порядок действий обычно такой.

1. Включил WP_DEBUG_LOG и открыл главную. В debug.log появилась строка с Fatal error в файле плагина слайдера.
2. Посмотрел дату изменения папки плагина — она совпадала с ночным автообновлением.
3. Переименовал папку плагина. Сайт открылся, слайдер на главной пропал.
4. Скачал предыдущую версию плагина, загрузил вместо новой, отключил для него автообновление.
5. Выключил режим отладки, удалил debug.log.
6. Настроил SMTP, чтобы письма о критических ошибках доходили.

Частая причина в таких случаях — новая версия плагина требует более свежий PHP, чем установлен на хостинге. Тогда сайт переводят на новую версию PHP через копию, проверяют и только потом снова обновляют плагин.

Автообновления: включать или нет

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

Разумный компромисс:

• автообновления ядра для минорных версий — включены (это исправления безопасности);
• автообновления плагинов безопасности и небольших проверенных плагинов — включены;
• WooCommerce, конструкторы страниц, платёжные модули, тема — вручную, после копии;
• настроенная почта, чтобы письма о сбоях доходили.

Отключить автообновление конкретного плагина можно в списке плагинов, ссылкой «Отключить автообновления» в его строке.

Если debug.log пустой

Бывает, что лог не создаётся. Проверьте:

• права на запись в /wp-content — файл должен создаваться от имени пользователя PHP;
• не переопределён ли путь к логу: WP_DEBUG_LOG может содержать путь вместо true;
• не падает ли сайт раньше загрузки WordPress — тогда ошибка будет в логе PHP или веб-сервера на хостинге;
• не отдаёт ли белую страницу кэширующий плагин или CDN: откройте сайт с параметром ?nocache=1.

Чек-лист восстановления

1. Проверить почту администратора на письмо о режиме восстановления.
2. Включить WP_DEBUG_LOG, найти Fatal error.
3. Отключить виновника переименованием папки.
4. Если нужно — вернуть версию PHP или предыдущую версию плагина.
5. Удалить .maintenance, если он остался.
6. Выключить отладку, удалить debug.log.
7. Проверить главную, формы, корзину, админку.
8. Разобраться, почему сломалось, и закрыть причину.

Частые вопросы