Как обновлять WordPress через staging и сохранять откат
Клонируем сайт в закрытое окружение, проверяем ядро, плагины и тему, фиксируем миграции, переносим обновление в production и контролируем возврат.
Содержание
Staging — закрытая копия сайта для проверки изменений до посетителей. Она должна быть достаточно похожа на production по версиям PHP, MariaDB, Nginx, ядра и расширений, но не должна отправлять реальные письма, проводить платежи и попадать в поиск.
Цель staging — получить повторяемый план обновления и увидеть несовместимость. Копирование тестовой базы обратно в production обычно недопустимо: рабочий сайт за это время принимает новые данные.
Зафиксируйте версии и критические сценарии
Сохраните список компонентов до изменения, чтобы после теста точно знать исходные версии ядра, активных расширений, PHP и клиента базы:
wp core version
wp plugin list --fields=name,status,version,update --format=csv
wp theme list --fields=name,status,version,update --format=csv
php --version
mariadb --versionКоманды не обновляют сайт. К результатам добавьте сценарии: вход, публикация, поиск, форма, загрузка, заказ и cron — только те функции, которые действительно есть.
Создайте согласованную копию
Скопируйте базу и wp-content близко по времени. Измените домен staging штатным search-replace, который понимает сериализованные данные; простая SQL-замена способна повредить длины строк.
wp --path=/srv/www/staging.example.com search-replace \
'https://example.com' 'https://staging.example.com' \
--all-tables-with-prefix --skip-columns=guid --dry-runСначала изучите dry-run. Затем выполните без него на staging и только после отдельной копии. Закройте окружение HTTP-аутентификацией или доступом по IP, добавьте noindex и отключите реальные интеграции.
Обновляйте по одному логическому слою
Сначала прочитайте changelog и требования. Обновите один важный плагин или небольшую связанную группу, очистите относящийся к ней кеш и пройдите сценарии. Затем ядро и тему проверяйте тем же способом.
После каждого шага смотрите PHP-журнал, очередь cron, новые таблицы и предупреждения. Если обновление запускает миграцию, запишите длительность и возможность работы со старым кодом.
Повторите план в production
Перед рабочим окном сделайте свежий dump и копию uploads, включите обслуживание там, где возможна запись, и повторите те же версии и порядок. Не заменяйте production-базу staging-копией.
Сразу после обновления выполните проверки снаружи и из панели. Наблюдайте ошибки, время ответа, cron и доставку писем. Кеш очищайте контролируемо, чтобы не скрывать старый код.
Заранее определите откат
Для изменений без несовместимой миграции достаточно вернуть предыдущие файлы и очистить opcode/page cache. Если схема или содержимое базы больше не работает со старым кодом, нужен восстановленный комплект базы и файлов одного момента, а значит будет потеря данных после точки копии.
Не удаляйте предыдущий релиз до окончания окна наблюдения. Если проблема касается одного плагина и его данные совместимы назад, деактивируйте или верните только его; общий restore оставьте последним средством.
Выбор компонентов разобран в проверке плагинов и тем, а полный возврат — в статье о backup и восстановлении.
Источники
Самопроверка
Проверьте, что материал усвоен
Ответьте на все вопросы. Результат сохранится только в этом браузере и будет учтён в статистике прочитанных материалов.
Разбираем коротко
Частые вопросы
Можно ли считать staging полной копией production?
Он должен повторять важные версии и конфигурацию, но внешние платежи, письма и фоновые задачи отключают. Персональные данные по возможности обезличивают.
Почему деактивация плагина не всегда является откатом?
Плагин мог изменить таблицы или данные. Возврат кода не отменяет такую миграцию, поэтому до обновления нужна согласованная копия и проверка совместимости назад.
Можно ли перенести staging-базу обратно целиком?
Обычно нет: пока шёл тест, production принимал новые записи, формы и заказы. В production повторяют проверенную последовательность обновления, а не заменяют живую базу старой копией.
