Откатить WordPress на предыдущую версию я делаю обычно после неудачного обновления: ядро, плагин или тема ломают фронт или админку, а разбираться в логах некогда. Разница между получасовой паникой и десятиминутным восстановлением - это бэкап и понимание, что именно откатывать: файлы ядра, конкретный плагин, тему или базу данных. Ниже рабочий порядок для каждого случая, с конкретными командами и местами, где физически лежат старые версии файлов.
Когда стоит откатить WordPress на предыдущую версию
Чаще всего откат нужен в трёх ситуациях. Первая - автообновление плагина среди ночи привело к белому экрану на проде, и клиент увидел это раньше меня. Вторая - обновление ядра до новой мажорной версии конфликтует со старой темой или кастомным кодом в functions.php, и часть виджетов перестаёт рендериться. Третья - плагин эквайринга или доставки после апдейта меняет формат данных, и заказы перестают проходить.
У одного клиента на WooCommerce с приёмом платежей через T‑Bank и доставкой через СДЭК автообновление плагина эквайринга за одну ночь отключило кнопку оплаты на чекауте: новая версия плагина требовала другой формат передачи суммы в API, и запросы падали с ошибкой. Плагин откатили до предыдущей версии за пять минут, а миграцию на новый формат уже спокойно тестировали отдельно.
Прежде чем откатывать что-либо, фиксирую текущее состояние: экспортирую базу и архивирую wp-content, даже если сайт уже не работает. Это страховка на случай, если откат тоже пойдёт не по плану.
| Компонент | Источник предыдущей версии | Инструмент отката |
|---|---|---|
| Ядро | Архив релизов на wordpress.org | Файловый менеджер, FTP или WP-CLI |
| Плагин из каталога | Вкладка Advanced View на странице плагина | Загрузка zip, WP-CLI, WP Rollback |
| Тема из каталога | Вкладка Advanced View на странице темы | Загрузка zip, WP-CLI |
| База данных | Дамп из бэкапа или экспорт хостинга | phpMyAdmin, WP-CLI, плагин бэкапов |
Откат ядра WordPress вручную и через WP-CLI
У WordPress нет кнопки «откатить версию» в панели администратора. Автообновления идут только вперёд, поэтому возврат к прежнему ядру делается руками или через WP-CLI.
Ручной способ: на wordpress.org/download/releases/ лежат архивы всех выпущенных версий, включая довольно старые. Скачиваю нужный zip, распаковываю и через файловый менеджер хостинга или по FTP заменяю папки wp-admin и wp-includes - именно их обновляет ядро при апдейте. Папку wp-content не трогаю: там темы, плагины и загрузки, откат ядра на них не влияет. Файл wp-config.php тоже не трогаю, он не входит в архив ядра.
Через WP-CLI откат делается одной командой, если есть SSH-доступ:
wp core download --version=6.4.3 --forceФлаг - force перезаписывает существующие файлы ядра без вопросов, - version задаёт нужный номер. После отката проверяю таблицу wp_options на предмет db_version: если новая версия ядра успела обновить схему базы, а откатываю я только файлы, между кодом и структурой таблиц возникнет несовместимость. В большинстве минорных обновлений (6.4.2 на 6.4.1) схема не меняется, а при откате через мажорную версию назад лучше откатывать ядро вместе с базой.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как вернуть плагин к прежней версии
Плагин откатывается проще ядра, если он есть в официальном каталоге wordpress.org. На странице плагина есть вкладка Advanced View, а в ней выпадающий список Previous Versions с архивами всех релизов за всю историю плагина. Скачиваю нужный zip и в админке иду в Плагины -> Добавить новый -> Загрузить плагин, ставя его поверх текущей версии.
Быстрее это делается через WP-CLI:
wp plugin install woocommerce --version=8.3.1 --forceКоманда ставит именно ту версию, что указана в - version, без удаления настроек плагина - они хранятся в базе, а не в файлах. Для повторяющихся откатов удобен бесплатный плагин WP Rollback: он добавляет кнопку «Rollback» прямо в списке плагинов и сам скачивает нужную версию, без ручного поиска архивов.
Момент, который часто упускают: если у плагина между версиями сменился формат хранимых настроек через миграцию при активации, откат файлов не откатывает уже изменённые записи в базе. В истории с плагином эквайринга это как раз произошло - пришлось руками поправить два поля в таблице wp_options, которые новая версия успела переписать в другом формате.
Откат темы к рабочему состоянию
С темами из каталога wordpress.org всё так же, как с плагинами: Advanced View, Previous Versions, либо команда wp theme install с флагом - version и - force через WP-CLI. Сложнее с кастомными и купленными на маркетах темами - у них обычно нет публичного архива версий, и единственный источник отката - бэкап или git-история, если тема разрабатывалась с версионированием.
Если тема кастомная и без git, до следующего инцидента стоит завести простую привычку: перед каждым обновлением темы или крупной правкой архивировать папку темы с датой в названии. Это не резервное копирование всего сайта, а страховка именно на случай неудачного обновления, занимает тридцать секунд.
Заниматься этим вручную после каждого инцидента неудобно, поэтому регулярное резервное копирование и проверку обновлений WordPress перед раскаткой на прод я обычно закрываю через техническую поддержку сайта на WordPress: бэкапы по расписанию, тестовое окружение для проверки обновлений и откат в течение часа, если что-то пошло не так на проде.
Восстановление базы данных из бэкапа
База откатывается отдельно от файлов, и это тот шаг, где чаще всего теряют данные - потому что делают его не полностью или в неправильном порядке. Сначала выгружаю текущую базу как есть, на случай если откат тоже не подойдёт, и только потом импортирую нужный дамп.
Через phpMyAdmin: вкладка Экспорт для бэкапа текущего состояния, потом Импорт и выбор файла .sql с нужной датой. Для больших баз, от 200-300 МБ, phpMyAdmin часто упирается в лимит времени выполнения и размер загрузки - в этом случае надёжнее WP-CLI:
wp db export before-rollback.sql
wp db import backup-2026-08-20.sqlОба формата дампа взаимозаменяемы, если бэкап делался стандартным mysqldump или встроенным экспортом плагинов вроде UpdraftPlus. После импорта старой базы проверяю префикс таблиц в wp-config.php: если он отличается от префикса в дампе, что бывает после переноса сайта или смены хостинга, сайт покажет ошибку подключения к базе, хотя данные на месте, просто WordPress ищет не те таблицы.
Если бэкапов нет: что делать
Без бэкапа откат превращается в частичное восстановление, а не полный возврат назад. Файлы ядра и публичных плагинов всегда можно взять из архива на wordpress.org, для этого бэкап не нужен, версии есть на сайте разработчика. Проблема начинается с кастомным кодом и данными в базе.
Первым делом проверяю, есть ли автоматические снапшоты на стороне хостинга. Большинство панелей, включая Timeweb, Beget и REG.RU, хранят ежедневные бэкапы за последние 7-14 дней даже без установленных плагинов резервного копирования, и восстановление занимает пару кликов в личном кабинете. Дальше смотрю ревизии записей в таблице wp_posts: WordPress хранит историю правок постов и страниц, это не спасёт от сломанной темы, но может вернуть текст, который случайно затёрли при откате контента. Если ничего из этого нет, руками сверяю changelog плагина или ядра между версиями и переписываю только то, что реально изменилось, вместо отката вслепую.
Ситуация, где откат не помогает вообще - если проблема не в обновлении, а в заражении сайта вредоносным кодом, который уже успел попасть и в файлы, и в бэкапы за несколько дней. Тогда возврат к более ранней резервной копии без анализа может просто вернуть уже заражённую версию сайта.
| Способ отката | Когда использую | Примерное время |
|---|---|---|
| Файловый менеджер хостинга или FTP | Нет SSH-доступа, откат одного-двух компонентов | 10-20 минут |
| WP-CLI | Есть SSH-доступ, нужен точный контроль версии | 2-5 минут |
| Плагин WP Rollback | Повторяющиеся откаты плагинов и тем без консоли | 3-7 минут |
| Снапшот хостинга | Нет бэкапов, нужен полный откат файлов и базы разом | 15-40 минут |
Частые вопросы
Как откатить WordPress на предыдущую версию без доступа к FTP?
Если хостинг даёт файловый менеджер в панели управления, а он есть почти у всех - Timeweb, Beget, REG.RU, Cloud.ru, замена файлов ядра или плагина делается прямо там, без отдельного FTP-клиента. Ещё вариант - плагин WP Rollback или загрузка zip-архива плагина через стандартную форму «Добавить новый» в админке, тогда доступ к файловой системе вообще не нужен.
Что будет с базой данных, если откатить только ядро WordPress?
В большинстве случаев ничего страшного: WordPress хранит номер версии схемы базы в таблице wp_options, и при откате на минорную версию, например с 6.4.3 на 6.4.1, схема обычно не менялась. Риск появляется при откате через мажорную версию назад - тогда стоит проверить changelog на предмет изменений структуры таблиц и, если они были, откатывать базу вместе с файлами.
Можно ли откатить WordPress через хостинг-панель без плагинов?
Да, если хостинг делает автоматические снапшоты всего аккаунта: файлы и база восстанавливаются вместе одним действием в панели, без ручной работы с WP-CLI или phpMyAdmin. Минус в том, что точки восстановления обычно идут раз в сутки, и откатиться на состояние часовой давности так не получится, только на ближайший ночной снапшот.
Как узнать, какая версия плагина была до обновления?
Если автообновления включены, WordPress присылает письмо с указанием, до какой версии обновился плагин, по нему легко посчитать на одну-две версии назад в changelog. Без письма смотрю вкладку Changelog плагина на wordpress.org и дату последнего использования сайта без сбоев, либо ищу дату инцидента в логах хостинга и беру версию, актуальную на день до него.