Обновление WordPress сломало сайт - с этим я сталкивался десятки раз: то ядро выкатывает мажорную версию и ломает совместимость с темой, то плагин обновляется без предупреждения и тянет за собой фатальную ошибку PHP. Ниже - рабочий алгоритм отката к прежней версии и схема обновлений, которая на моей практике почти исключает такие ситуации.
Почему обновление WordPress приводит к поломке сайта
Чаще всего проблема не в самом ядре WordPress - его обновления тестируются достаточно тщательно. Ломается стык между компонентами:
- Плагин не успел выпустить патч под новую версию PHP или ядра - типичная история с WooCommerce и платёжными модулями вроде интеграции с Т‑Банк, где после обновления шлюз перестаёт принимать вебхуки об оплате.
- Тема жёстко завязана на устаревшие хуки - после мажорного апдейта часть функций помечается deprecated, и шаблон выдаёт fatal error вместо страницы.
- Хостинг тихо поднял версию PHP вместе с обновлением WordPress, а старый плагин для интеграции с СДЭК на неё не рассчитан.
- Два плагина одновременно перехватывают один и тот же хук и после обновления начинают конфликтовать - раньше это маскировалось версией кода, которая обновилась только с одной стороны.
Отдельно скажу про автообновления. Если в настройках включено автоматическое обновление плагинов и тем, поломка происходит ночью или под утро, когда её никто не видит несколько часов - а для интернет-магазина каждый час простоя это упущенные заказы.
Первые признаки: белый экран, ошибка 500 и фатальные ошибки PHP
После неудачного обновления сайт обычно падает одним из трёх способов, и по симптому можно сразу понять направление поиска.
Белый экран смерти (WSOD)
Страница просто пустая, без текста ошибки. Это значит, что PHP упал с фатальной ошибкой, но вывод отладки выключен. Первым делом включаю в wp-config.php строки WP_DEBUG и WP_DEBUG_LOG, чтобы увидеть реальный текст ошибки в файле wp-content/debug.log вместо пустого экрана.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Ошибка 500 Internal Server Error
Это чаще признак того, что упал .htaccess или лимит памяти PHP. Проверяю логи сервера - на хостингах с cPanel они лежат в разделе Errors, на VPS смотрю /var/log/nginx/error.log или аналогичный лог PHP-FPM.
Ошибка совместимости версии PHP
Если в логе видно что-то вроде Uncaught Error: Call to undefined function, дело почти всегда в плагине, который не обновили под новую версию PHP или WordPress. Это самая частая причина, с которой ко мне обращаются владельцы магазинов на WooCommerce после планового апдейта хостинга.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как быстро откатить WordPress до рабочей версии
Паниковать и переустанавливать всё с нуля не нужно - в 90% случаев достаточно вернуть один компонент к прежней версии.
Откат плагина или темы через админку
Если доступ в админ-панель ещё есть, самый быстрый вариант - плагин WP Rollback. Он ставится за пару минут, и в списке установленных плагинов появляется кнопка «Rollback», которая тянет предыдущие версии прямо из официального репозитория WordPress.org. Для плагинов, которых нет в репозитории (купленных на отдельных маркетплейсах), этот способ не сработает - там откатываю вручную через FTP.
Откат ядра WordPress
Старую версию ядра можно скачать прямо с https://ru.wordpress.org/download/releases/, распаковать и заменить папки wp-admin и wp-includes через FTP или файловый менеджер хостинга - папку wp-content при этом не трогаю, там темы, плагины и загрузки.
Ручной откат через FTP при недоступной админке
Если админка не открывается вообще, подключаюсь по FTP или через файловый менеджер хостинга, нахожу папку проблемного плагина в wp-content/plugins/ и либо переименовываю её (WordPress автоматически деактивирует плагин с ошибкой при переименовании папки), либо заменяю содержимое на версию из бэкапа.
# переименование папки плагина деактивирует его без доступа в админку
mv wp-content/plugins/problem-plugin wp-content/plugins/problem-plugin-disabledВосстановление из резервной копии, если откат плагина не помог
Если проблема не в одном компоненте, а обновление зацепило базу данных (миграции таблиц WooCommerce, обновление структуры мета-полей), точечный откат плагина не спасёт - нужен полный откат из бэкапа.
| Способ отката | Когда применять | Время восстановления |
|---|---|---|
| Откат плагина/темы (WP Rollback, FTP) | Ошибка локализована в одном компоненте | 5-15 минут |
| Снапшот хостинга (JetBackup, cPanel Backup) | Есть автоматические снимки за последние сутки | 10-30 минут |
| Ручное восстановление из дампа БД + архива файлов | Автобэкапов нет или они устарели | 30-90 минут |
| Восстановление на staging с последующей заменой | Нужно проверить перед выкаткой на прод | 1-3 часа |
Большинство хостингов держат ежедневные снапшоты 7-14 дней - в панели управления это обычно раздел Backup или JetBackup. Если своих бэкапов нет вообще, восстанавливать нечего, и на моей практике это самая частая причина, почему клиенты вместо часа простоя теряют сутки: сайт приходится собирать заново по кускам из кэша поисковика и старых экспортов товаров.
Если разбираться в дампах БД и структуре файлов самостоятельно рискованно - я беру такие восстановления и последующую техническую поддержку сайтов на WordPress на себя, включая настройку автоматических бэкапов, чтобы следующая поломка не превращалась в аврал.
Как обновляться безопасно и не ловить поломку каждый раз
После нескольких десятков подобных случаев у меня сложилась рабочая схема, которая почти исключает падение прод-сайта после обновления.
Тестовое окружение перед прод-обновлением
Staging-копия сайта (либо встроенная функция хостинга, либо плагин типа WP Staging) - минимальное требование для магазина с оборотом. Обновление сначала прогоняю на копии, проверяю ключевые сценарии - оформление заказа, оплату через эквайринг, расчёт доставки через СДЭК - и только потом переношу на боевой сайт.
Поэтапное обновление вместо «обновить всё разом»
Никогда не обновляю ядро, все плагины и тему одним кликом. Порядок такой: сначала плагины по одному с проверкой сайта между шагами, потом тема, и в последнюю очередь ядро. Так при поломке сразу понятно, какой конкретно апдейт её вызвал, а не приходится откатывать пять компонентов подряд методом исключения.
Автоматизация проверки после обновления
Для клиентов с интернет-магазинами настраиваю в n8n сценарий, который после каждого обновления плагинов проверяет доступность ключевых страниц (главная, карточка товара, чекаут) и присылает уведомление в Telegram, если код ответа не 200 - это ловит поломку за минуту, а не когда покупатель напишет в поддержку.
Резервная копия перед каждым обновлением - без исключений
Правило простое: ни одно обновление не запускается без свежего бэкапа файлов и базы данных, сделанного прямо перед апдейтом, а не вчерашнего автоматического снимка. Это тридцать секунд на плагине типа UpdraftPlus против нескольких часов восстановления вручную.
WooCommerce, эквайринг и интеграции - отдельная зона риска
Если на сайте стоит WooCommerce с оплатой через Т‑Банк или доставкой через СДЭК, обновление ядра или самого WooCommerce способно молча отключить вебхук приёма платежей - заказы будут создаваться, но статус оплаты не обновится, и покупатель формально не получит подтверждения. После любого крупного обновления магазина я всегда тестово провожу заказ с реальной картой на минимальную сумму и проверяю, что статус в админке меняется автоматически, а не только приходит письмо от платёжной системы.
То же самое с расчётом стоимости доставки СДЭК - после обновления плагина интеграции стоит пересчитать доставку в паре тестовых заказов на разные города, потому что тарифная сетка API иногда меняется независимо от версии плагина.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Сколько времени занимает откат WordPress после неудачного обновления?
Если под рукой актуальный бэкап и доступ по FTP или в панель хостинга, откат одного плагина или темы занимает 10-15 минут. Полное восстановление из дампа базы данных и архива файлов - от получаса до полутора часов, в зависимости от размера сайта и скорости загрузки бэкапа на сервер.
Можно ли откатить только один плагин, не трогая остальной сайт?
Да, и это предпочтительный вариант, если ошибка локализована. Плагин WP Rollback возвращает предыдущую версию прямо из репозитория WordPress.org без затрагивания ядра, темы и остальных плагинов. Для плагинов с отдельных маркетплейсов откат делаю вручную через FTP, заменяя папку плагина на версию из бэкапа.
Что делать, если бэкапов сайта вообще нет?
Проверяю панель хостинга - многие держат автоматические снапшоты за последние 7-14 дней даже без отдельной настройки бэкапов клиентом, это часто спасает ситуацию. Если снапшотов нет, восстанавливаю сайт частично: структуру через экспорт из кэша поисковых систем, товары и контент - вручную. После такого восстановления обязательно настраиваю автоматическое резервное копирование, чтобы повторный инцидент не превращался в ту же историю.
Как понять, что именно сломало сайт - плагин, тема или ядро?
Включаю WP_DEBUG_LOG и смотрю файл wp-content/debug.log - там указан конкретный файл и функция, вызвавшая ошибку, обычно с явным указанием пути к плагину или теме. Если лог пустой, а сайт всё равно недоступен, проверяю логи сервера (error.log Apache/Nginx или PHP-FPM) - там видна ошибка уровня сервера, например превышение лимита памяти после обновления ядра.