Нажали «Обновить» - и вместо сайта белый экран или сообщение «На сайте возникла критическая ошибка». Первое желание - откатить все сразу. Не спешите. Я Андрей, и в такой ситуации иду по порядку: возвращаю доступ, ищу причину, потом проверяю, как избежать повторения.
Обновление WordPress сломало сайт: первые пять минут
- Остановите обновления. Запишите, что нажали и примерно когда. Обновили несколько плагинов - перечислите все. Потом не придется гадать.
- Проверьте почту администратора, включая спам. Начиная с WordPress 5.2 защита от критических ошибок может прислать ссылку для восстановления. По ней администратор входит, пока проблемный плагин или тема приостановлены. В письме иногда указана причина сбоя.
- Посмотрите, что WordPress приостановил. Если ссылка сработала, прочитайте уведомление в режиме восстановления. Не включайте плагин обратно просто ради проверки - зацепка уже есть.
- Сверьте симптомы с советами ниже. Зависшее сообщение об обслуживании и неработающая оплата требуют разных действий.
- Пока не восстанавливайте весь сайт. У магазина в бэкапе, сделанном утром, не будет дневных заказов. Сперва найдите поломку.
Подберите решение по симптомам
Смотрите на то, что происходит. Странный вид страницы еще не значит, что сайт упал. И наоборот: страница открывается, а заказ оформить нельзя.
Белый экран или критическая ошибка. Проверьте журнал ошибок, затем отключите подозрительный плагин или смените тему. Как именно - в следующем разделе.
«Сайт ненадолго закрыт на техническое обслуживание» не исчезает. Через SFTP или файловый менеджер хостинга удалите файл .maintenance в корневой папке WordPress. Именно файл, не папку с похожим названием. Обновите страницу.
Не попасть в wp-admin. Переименуйте папку подозрительного плагина через SFTP или файловый менеджер. Если пользуетесь WP-CLI, отключите его там. Данные в панике не удаляйте.
Съехала верстка, но ошибок нет. Очистите кеш сайта, хостинга и CDN, если он есть. Откройте страницу в приватном окне. Иногда обновление прошло успешно, а старые стили застряли в кеше.
Форма не отправляется или оплата не проходит. Проверяйте действие целиком, а не только загрузку страницы. Для магазина это важнее кривого заголовка.
«Уже выполняется другое обновление». Подождите около 15 минут. Если обновление не идет, а сообщение осталось, пользователи WP-CLI могут выполнить wp option delete core_updater.lock.
«Не удалось создать каталог» или «Не удалось скопировать файл». WordPress не может записать файлы, часто в wp-content. Попросите хостинг проверить свободное место, затем права доступа.
«Ошибка загрузки». Сервер мог не связаться с WordPress.org или поставщиком плагина. Повторите попытку позже. У платного плагина проверьте лицензию.
Плагин пропал после неудачного обновления. Установите тот же плагин заново через экран «Плагины». Настройки обычно остаются в базе, но потом обязательно их проверьте.
Как найти плагин, который все сломал
Если режим восстановления не назвал виновника, откройте wp-config.php через SFTP или файловый менеджер. Перед строкой с просьбой прекратить редактирование добавьте настройки ниже. Если они уже есть, поменяйте значения, не создавайте дубли:
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-content/plugins, например из plugin-name в plugin-name-off. Через WP-CLI используйте wp plugin deactivate plugin-name. Обновите страницу. Заработало? Оставьте плагин выключенным, пока не разберетесь с версией и совместимостью.
Не удалось сузить круг - переименуйте всю папку plugins в plugins-off. Вернув доступ, переименуйте ее обратно и включайте плагины по одному. Между включениями проверяйте сайт. Если обновляли тему, активируйте уже установленную стандартную тему. Команда WP-CLI: wp theme activate THEME-SLUG; вместо заглушки нужен настоящий slug.
Закончили поиск - установите для WP_DEBUG и WP_DEBUG_LOG значение false, затем удалите wp-content/debug.log. В журнале могут остаться данные, которые лучше не хранить на сервере.
Как безопасно откатить обновление
Если виноват плагин, вернитесь к версии, на которой сайт работал. Для плагина с WordPress.org через WP-CLI можно поставить конкретную версию: wp plugin install plugin-name --version=X.Y.Z --force. Замените обе заглушки настоящим slug и номером версии. Другой путь - восстановить из бэкапа только файлы нужного плагина или темы. После этого проверьте сайт.
Перед восстановлением всего сайта выясните, что появилось после бэкапа: заказы, заявки, товары, правки текстов. Сперва сохраните эти данные. Не меняйте сегодняшние заказы на работающую главную страницу. Если у вас WooCommerce и сами файлы отделить не получается, попросите точечное восстановление.
У WordPress есть встроенная подстраховка, но она не ловит все. В версии 6.3 появился автоматический откат, если ручное обновление плагина или темы сорвалось при установке. В 6.6 добавили откат автообновления плагина, если сразу после него возникла критическая ошибка. Режим восстановления может пустить администратора внутрь с приостановленным компонентом. Но ни одна из этих мер не заметит сломанную верстку, ошибку JavaScript в форме записи или оформление заказа, которое открывается, но не принимает оплату. Contact Form 7 6.2 вызвал критические ошибки на части сайтов. Если обновляли его, вот инструкция по восстановлению после Contact Form 7 6.2.
Как обновлять сайт без лишних сюрпризов
Небольшому сайту не нужен сложный процесс релизов. А вот понять, сработало ли обновление, нужно. Я бы делал так:
- Сделайте бэкап прямо перед обновлением. Вы должны знать, где он лежит и как его восстановить. Непроверенный бэкап - еще не гарантия.
- Крупные изменения сначала проверяйте на тестовой копии. Особенно конструктор страниц, WooCommerce и тему. Боевой магазин - плохое место для знакомства с новым шаблоном оплаты.
- Читайте список изменений. Перед крупным обновлением сравните требования плагина к PHP с версией PHP на хостинге. Кнопка «Обновить» совместимость не обещает.
- Обновляйте по одному компоненту. Не жмите «Обновить все». После каждого шага проверяйте сайт - так проще найти виновника.
- Выбирайте время. Не пятница вечером и не час до распродажи. Оставьте запас на проверку и откат.
- Автообновления включайте выборочно. Небольшим и защитным плагинам они могут подойти. Конструктор страниц, WooCommerce и тему я бы обновлял вручную.
- Не копите обновления месяцами. Чем больше скачок между версиями, тем сложнее распутывать сбой.
- Включите мониторинг доступности. Круглосуточный мониторинг WordPress сообщит о белом экране раньше покупателя. Но тестовый заказ он не заменит: страница оплаты может открываться и при этом не работать.
- Проверяйте совместимость сами. WordPress.org проверяет выпуски плагинов на вредоносный код, а не на дружбу с вашей темой, версией PHP и другими плагинами. Подробнее - в статье о том, как WordPress проверяет обновления плагинов перед выпуском.
Почему обновления WordPress ломают сайты
Обычно апдейт не ломает движок сам по себе, а вскрывает несовместимость. Два плагина могут ждать разные версии одного кода. Плагину может понадобиться более свежий PHP - или хостинг сам поменяет версию PHP. Еще частые причины: переопределенные шаблоны темы и WooCommerce, крупный апдейт конструктора страниц, свой код в functions.php, который опирался на старое поведение. Добавьте сюда месяцы пропущенных обновлений. А иногда обновление вообще прошло нормально - результат просто прячут старые CSS или JavaScript в кеше.
Проверка за 10 минут после каждого обновления
Зеленое сообщение об успехе говорит только о том, что установка закончилась. Прежде чем закрыть ноутбук, откройте главную и страницу, собранную в конструкторе: не пропали ли блоки и стили? Отправьте тестовую заявку и проверьте, пришло ли сообщение. Для магазина оформите пробный заказ способом оплаты, который можно безопасно проверить.
Затем войдите в wp-admin, откройте страницы, которые обычно редактируете, очистите кеши и повторите проверку в приватном окне. Беглого взгляда на главную тут мало. Что-то не работает - остановитесь и разберите последнее обновление.
Что сделать сегодня
Если сайт уже сломан, сначала проверьте письмо для восстановления, в том числе в спаме. К бэкапу переходите после этого. Когда сайт оживет, выделите в календаре время на бэкап и проверку перед следующим апдейтом. Не хотите заниматься этим сами - обслуживание сайта на WordPress включает обновления, бэкапы и проверки. А прямо сегодня отправьте тестовую форму или оформите тестовый заказ. Только после этого называйте сайт починенным.