«На сайте возникла критическая ошибка» в WordPress: что делать

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

Первое желание - начать нажимать всё подряд. Не надо. Эта ошибка выглядит страшно, но обычно сайт можно вернуть довольно быстро и ничего не потерять. Главное - действовать по порядку.

Первые пять минут: остановите потери

1. Поставьте рекламу на паузу. Если идут кампании в Директе или ВКонтакте, остановите их. Каждый клик сейчас ведёт на неработающий сайт.
2. Вспомните, что менялось. Обновляли плагин? Ставили новую тему? Правили код? Хостинг писал про смену версии PHP? Чаще всего виновник находится именно здесь.
3. Проверьте почту администратора сайта. Об этом ниже, это самый простой путь.

Что вообще значит эта ошибка

За фразой «критическая ошибка» скрывается фатальная ошибка PHP: какой-то код на сайте сломался так, что WordPress не может продолжить работу. Посетителям WordPress специально не показывает подробности, чтобы не раскрывать устройство сайта. Поэтому на экране общая фраза, а настоящая причина спрятана.

Частые причины:

• обновление плагина, который несовместим с другим плагином, темой или версией PHP;
• обновление или смена темы;
• смена версии PHP на хостинге: старые плагины и темы могут не работать на новой версии;
• правка кода, например в functions.php, с одной лишней скобкой;
• нехватка памяти на хостинге.

Шаг 1. Письмо с режимом восстановления

Начиная с версии 5.2, при критической ошибке WordPress пытается отправить письмо на адрес администратора сайта. В письме написано, какой плагин или тема вызвали ошибку, и есть ссылка на режим восстановления.

По этой ссылке вы попадёте в админку, даже когда сайт лежит. Там можно отключить сломанный плагин или переключить тему, и сайт оживёт. Проверьте почту, включая спам.

Если письма нет (почта с сайта часто не доходит, это отдельная беда WordPress), переходите к следующим шагам.

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

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

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

Обновите страницу сайта. Ошибки начнут записываться в файл wp-content/debug.log, а посетители их не увидят. Откройте журнал: там будет путь к файлу, в котором всё сломалось. Если путь содержит wp-content/plugins/название-плагина/, виновник найден. Если wp-content/themes/, дело в теме.

После починки верните WP_DEBUG в false.

Шаг 3. Отключите виновника

Если виноват плагин. Зайдите через файловый менеджер или FTP в папку wp-content/plugins/ и переименуйте папку проблемного плагина, например допишите в конце -off. WordPress не найдёт плагин и отключит его. Если непонятно, какой именно плагин виноват, переименуйте всю папку plugins, убедитесь, что сайт ожил, верните имя и включайте плагины по одному в админке.

Если виновата тема. Так же переименуйте папку темы в wp-content/themes/. Если в системе есть стандартная тема WordPress, сайт переключится на неё. Выглядеть будет непривычно, зато админка откроется.

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

Шаг 4. Если ничего не помогло - бэкап

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

Если бэкапа нет... Об этом ниже, и лучше прочитать это до того, как он понадобится.

Чего не делать

Не правьте файлы через редактор тем в админке. Раздел «Внешний вид → Редактор файлов тем» выглядит удобно, но это опасный инструмент. Перед сохранением WordPress проверяет код, отправляя запрос самому себе. На части хостингов эта проверка не срабатывает, и я своими глазами видел, как после такого сохранения файл темы оказывался пустым, в ноль байт, и сайт ложился целиком. Любые правки .php делайте через файловый менеджер хостинга, FTP или SSH и только после резервной копии.

Не обновляйте всё подряд, пытаясь «починить». Пять обновлений одновременно превращают одну поломку в пять.

Не удаляйте плагины целиком в панике. Переименование папки отключает плагин и легко откатывается. Удаление может стереть его настройки.

Как сделать резервную копию сайта на WordPress

Бэкап - это копия двух вещей: файлов сайта и базы данных. В файлах лежат WordPress, темы, плагины и загруженные картинки. В базе - страницы, записи, настройки, пользователи. Одно без другого не восстановит сайт.

Способы:

• Через панель хостинга. Многие хостинги делают копии автоматически и позволяют создать копию вручную. Узнайте, как часто они делаются и сколько хранятся.
• Плагином резервного копирования. Удобно, особенно если плагин умеет отправлять копии во внешнее хранилище.
• Вручную. Архив файлов через файловый менеджер плюс экспорт базы через phpMyAdmin.

Три правила, которые спасают сайты:

1. Копия должна лежать не только на том же сервере. Если сервер недоступен, копия рядом с ним бесполезна.
2. Делайте копию перед любыми изменениями: обновлениями, новым плагином, правками кода.
3. Хотя бы раз проверьте восстановление. Бэкап, который не получается развернуть, - это не бэкап.

Как временно закрыть сайт на технические работы

Если вы чините сайт или обновляете что-то крупное, посетителям лучше видеть аккуратную заглушку «ведутся технические работы», а не сломанные страницы. Для этого есть плагины режима обслуживания. Во время обновлений WordPress и сам ненадолго показывает такую заглушку.

Но если сайт лежит больше нескольких часов, главное - не заглушка, а пауза в рекламе и сообщение клиентам в соцсетях, что вы на связи.

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

• Правки в дочерней теме или отдельных сниппетах, чтобы обновление темы их не стирало.
• Обновления сначала на копии сайта, потом на рабочем.
• Регулярные бэкапы во внешнее хранилище.
• Мониторинг, который сообщит о падении сайта раньше, чем клиенты.
• Рабочая отправка почты через SMTP, чтобы письма о сбоях доходили.

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

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