Обновление WordPress до новой мажорной версии без поломок

Мажорные версии WordPress выходят раз в 4-6 месяцев. Безопасный порядок один: свежий бэкап, обновление на копии, проверка главных сценариев, потом бой. Само обновление занимает минуты, вся процедура с проверкой на типовом сайте укладывается в час.

Мажорное обновление WordPress (с 6.x на 6.x+1) выходит раз в 4-6 месяцев. Каждый раз владельцы сайтов делятся на тех, кто жмёт Update в админке без подготовки и потом разбирается с белым экраном, и тех, кто откладывает обновление три года, потому что страшно. Оба подхода плохие.

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

Стрелка обновления вокруг логотипа со щитом

Зачем обновляться вообще

Три причины:

Безопасность. Мажорные обновления закрывают уязвимости. Не патч и не minor (которые ставятся автоматически), а серьёзные изменения архитектуры, недоступные на старых версиях.

Производительность. Каждый мажор приносит ускорения. Например, переход с 6.0 на 6.5 даёт 10-15 процентов прирост скорости рендера.

Совместимость с плагинами. Современные плагины требуют свежий WP. На устаревших версиях вы не сможете обновить Yoast, Wordfence, Elementor.

Если откладывать обновления годами, в какой-то момент несовместимость становится непреодолимой: новые плагины не работают на старом WP, старые плагины с уязвимостями нельзя оставить.

Major, minor и patch

В версионировании WordPress:

Patch: 6.5.1 → 6.5.2. Совсем мелкие правки. Ставятся автоматически без вашего внимания.
Minor: иногда так называют patch-обновления. Не путать с другими СУ.
Major: 6.4 → 6.5. Новые функции, изменение поведения. Ставится вами вручную.

Major это то, что мы обсуждаем. Patch обычно проходят бесшумно.

Главные риски при мажорном обновлении

Что обычно ломается:

Несовместимость плагина

Плагин использовал внутреннюю функцию WP, которая в новой версии переименована или удалена. Сайт падает с белым экраном.

Несовместимость темы

Тема использует устаревшие хуки или функции. Падает фронтенд или админка.

Конфликт между плагинами

Один плагин обновился, другой нет. Они начинают мешать друг другу.

Изменения в Gutenberg

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

Изменения в REST API

Если у вас есть интеграции через REST API (мобильное приложение, интеграция с CRM), API может меняться.

Кеш

После обновления старый кеш может содержать ссылки на удалённые файлы. Лечится сбросом кеша.

Безопасный план обновления

Шаги, которые реально работают.

Шаг 1: подготовка

За день до обновления:

Проверить, что все плагины и тема имеют актуальные версии. Если какой-то плагин не обновлён больше года, уже сейчас оцените, нужен ли он, и есть ли совместимая замена.
Сделать ручной бэкап сайта. Файлы и база. Не полагайтесь только на автоматический бэкап хостинга, делайте свой.
Проверить версии PHP и MySQL. Современные WP требуют PHP 8.0+, MySQL 5.6+. Если у вас 7.4 или MySQL 5.5, обновляйте PHP сначала.
Запланируйте время. Идеально вечер пятницы или ночь, когда трафик минимальный. Не первый рабочий день после праздников.

Шаг 2: staging-копия

На большинстве хостингов есть кнопка Создать копию для тестирования. Если нет, делаем сами.

# На SSH хостинга
cp -r ~/saitfix.ru/public_html ~/staging.saitfix.ru/public_html
mysqldump -u user -p main_db | mysql -u user -p staging_db

В staging-копии в wp-config.php меняете WP_HOME и WP_SITEURL на staging-домен:

define('WP_HOME', 'https://staging.saitfix.ru');
define('WP_SITEURL', 'https://staging.saitfix.ru');

И запрещаете индексацию в Settings > Reading > Discourage search engines from indexing this site.

Шаг 3: обновление на staging

В админке staging-копии: Dashboard > Updates. Жмёте Update Now.

Через 1-3 минуты обновление завершается. Сразу проверяете:

Главная страница открывается.
Админка доступна, можно зайти.
Создание поста / товара работает.
Отправка формы работает.
Если магазин: корзина и оформление заказа работают.

Если что-то падает, разбираетесь:

Open wp-content/debug.log. Включите WP_DEBUG_LOG = true в wp-config.php.
Найдите файл с фатальной ошибкой.
Часто это файл темы или плагина.
Деактивируйте подозрительный, попробуйте ещё раз.

Если плагин падает, ищите его обновление. Если автор не обновил, ищите замену или совместимую версию.

Шаг 4: тестовый прогон

После того как staging работает, прогоняете типовые сценарии:

Создание контента.
Отправка формы заявки.
Если магазин: добавление в корзину, оформление заказа.
Если личный кабинет: вход, выход, редактирование профиля.
Поиск по сайту.
Печать страницы (если важно).

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

Шаг 5: обновление прода

Если на staging всё хорошо, переходите на прод. Алгоритм:

Сделайте свежий бэкап.
Включите режим обслуживания (плагин Maintenance Mode или просто заглушка через .htaccess).
В админке Dashboard > Updates, жмёте Update.
Снимаете режим обслуживания.
Проверяете главную и пару критичных страниц.
Сбрасываете кеш (если есть кеш-плагин).

В случае проблем сразу откатываетесь:

# Восстановление файлов
tar xzf backup-files.tar.gz -C ~/saitfix.ru/public_html
# Восстановление базы
mysql -u user -p main_db < backup-db.sql

Шаг 6: мониторинг

Первые 24 часа смотрите за:

Логи ошибок PHP в wp-content/debug.log.
Логи сервера в hosting panel.
Метрики Метрики: нет ли резких изменений в трафике, отказах.
Уведомления на email от Wordfence или другого плагина безопасности.

Если что-то не так, разбираетесь сразу. Бывает, что плагин начинает работать странно через несколько часов, и заметить это нужно быстро.

Типовые проблемы и решения

Белый экран после обновления

Симптом: сайт не открывается, пустой белый экран. Админка тоже.

Причина: фатальная ошибка PHP. Обычно конфликт плагина или темы с новым WP.

Лечение:

Подключитесь по FTP/SSH.
Переименуйте папку wp-content/plugins в plugins-backup. Это деактивирует все плагины разом.
Проверьте, открылся ли сайт. Если да, проблема в плагине.
Создайте обратно папку plugins, перенесите туда плагины по одному, проверяя после каждого.
Найдёте виновника, обновите его до совместимой версии или замените.

Если шаг 2 не помог, проблема в теме:

Подключитесь к базе через phpMyAdmin.
В таблице wp_options меняйте значения template и stylesheet на стандартную тему вроде twentytwentyfour.
Проверьте, открылся ли сайт. Если да, ищете замену старой теме или фиксите её код.

Админка работает, фронтенд не работает

Часто из-за кеша или конфликтов CSS/JS. Сбросьте кеш плагина, проверьте wp-content/cache/ и удалите вручную если нужно.

Шаблоны Gutenberg ломаются

После мажора в Gutenberg иногда появляется новая версия редактора, и старые блоки выглядят иначе. Часто визуально, иногда функционально.

Лечение: открываете старую страницу, видите предупреждение Block recovery. Восстанавливаете один в один или вручную пересохраняете блок.

Плагин не обновляется

В админке: Plugin update failed. Часто из-за лимитов памяти PHP или превышения тайм-аута.

Лечение:

// в wp-config.php
define('WP_MEMORY_LIMIT', '256M');
ini_set('max_execution_time', 300);

После этого попробуйте снова. Если всё равно не получается, обновите вручную: скачайте плагин с WP.org, распакуйте, замените папку в wp-content/plugins/.

REST API сломался

Если у вас интеграция с CRM или мобильным приложением через REST, после обновления она может не работать.

Лечение: проверьте, что плагины, делающие интеграцию, обновлены. Проверьте через https://saitfix.ru/wp-json/wp/v2/posts доступность базового API. Если 401 или 403, проверяете авторизацию.

Картинки исчезли

После обновления изображения не показываются. Часто это проблема с правами на папку uploads/ или с .htaccess, который перестал отдавать файлы.

Лечение: проверьте права (755 для папок, 644 для файлов), проверьте .htaccess на отсутствие странных правил.

Откат, если всё пропало

План B, который должен быть готов до обновления.

# 1. Восстановить файлы
cd ~/saitfix.ru/public_html
rm -rf wp-admin wp-includes
tar xzf ~/backup-files-pre-update.tar.gz

# 2. Восстановить базу
mysql -u user -p main_db < ~/backup-db-pre-update.sql

# 3. Сбросить кеш
rm -rf ~/saitfix.ru/public_html/wp-content/cache/*

Через 5-10 минут сайт работает в состоянии до обновления. Спокойно разбираетесь, что пошло не так, готовитесь к новой попытке.

WP-CLI: обновление через командную строку

Для тех, кто работает по SSH:

cd ~/saitfix.ru/public_html

# Бэкап перед
wp db export ~/backup-db-$(date +%F).sql
tar czf ~/backup-files-$(date +%F).tar.gz wp-content wp-config.php

# Обновление ядра
wp core update

# Обновление плагинов
wp plugin update --all

# Обновление темы
wp theme update --all

# Обновление базы (если нужно)
wp core update-db

# Сброс кеша
wp cache flush

Это быстрее, чем через админку, и работает без проблем с лимитами памяти.

Особенности для разных сценариев

Multisite

WP Multisite (сетевая установка нескольких сайтов на одной кодовой базе) обновляется через Network Admin > Updates. Сначала ядро, потом каждый сайт мигрируется отдельно через wp core update-db --network.

Тестировать сложнее: нужно проверить разные сайты в сети. Закладывайте больше времени.

WooCommerce

После обновления WP проверяйте отдельно WooCommerce. Иногда он требует свой собственный апгрейд базы данных. В админке появляется уведомление Database update required, жмёте, обновляете.

Тесты после обновления магазина: добавление в корзину, оформление заказа, проверка купонов, тест платёжного шлюза с тестовой картой.

Multilang (WPML, Polylang)

Если у вас многоязычный сайт, перед обновлением WP проверяйте, что ваш мультиязычный плагин совместим с новой версией. Иногда они отстают на месяц-два.

С большой базой подписок

WordPress Newsletter, MailPoet, Easy Digital Downloads. Перед обновлением сделайте ручной экспорт подписчиков и заказов. На случай, если плагин запустит database upgrade и что-то сломает.

Расписание обновлений

Что я делаю на абонентских клиентах:

Patch (6.5.x → 6.5.y): автоматически в течение недели после релиза. Бэкап делается, обновление накатывается, проверка по короткому чек-листу.
Major (6.5 → 6.6): через 2-3 недели после релиза, когда первая волна багов уже закрыта. Полный staging-тест, потом прод.
Плагины: еженедельно проверка, но обновления только после бэкапа и краткого теста.
Тема: реже, по необходимости. Кастомные правки в child-теме, чтобы не потеряться при обновлении родительской.

Чек-лист обновления

Проверена совместимость PHP и MySQL.
Все плагины и тема актуальны до обновления WP.
Сделан свежий бэкап файлов и базы.
Бэкап лежит вне вашего хостинга (S3, своя машина).
Создана staging-копия.
Обновление сначала на staging.
Прогон по чек-листу типовых сценариев на staging.
На проде режим обслуживания.
Свежий бэкап перед самим обновлением.
Обновление через админку или WP-CLI.
Сброс кеша.
Проверка типовых страниц.
Мониторинг ошибок 24 часа.
План отката готов и протестирован.

Когда стоит делегировать

Безопасное обновление WordPress на типичном сайте занимает 2-4 часа: бэкап, staging, тест, прод, мониторинг. На больших сайтах с WooCommerce и WPML до 6-10 часов из-за тщательной проверки.

Это входит в часовую ставку или в любой из тарифов на /#pricing. Если у вас сайт на старой версии WP, и страшно обновлять, опишите ситуацию через /#contact. Связанные материалы по WordPress в /blog/category/cms/, там есть отдельные статьи про WSOD, плагины и тормоза WP.

Частые вопросы

Как безопасно обновить WordPress

Снять полный бэкап файлов и базы, развернуть копию сайта, обновиться на ней, пройти по главным страницам и формам. Убедившись, что всё цело, повторить на боевом.

Чем мажорное обновление отличается от минорного

Минорные и патчи закрывают ошибки и уязвимости, ставятся автоматически и почти никогда не ломают. Мажорные меняют функциональность ядра, и вот их надо проверять.

Что чаще всего ломается

Старые плагины и темы, которые не обновляли годами. Ядро WordPress совместимость держит хорошо, проблемы приходят со стороны стороннего кода.

Можно ли откладывать обновления

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