Безопасное обновление WordPress: ядро, плагины и темы без риска

Почему обновления ломают сайты и почему без них нельзя

Обновление в WordPress — это не просто «заменить файлы». Вместе с файлами обновляются связи: функции, на которые опираются плагины, хуки, структура таблиц базы данных. Три самых частых сценария поломки:

• Плагин старее ядра. Разработчик писал код под WordPress 6.5, а вы обновились до 6.9 — функция, которую плагин вызывает, переименована или работает иначе. Результат — фатальная ошибка или тихо отвалившаяся функция.
• Тема конфликтует с плагином. Тема подключает свою копию jQuery, плагин — свою. Обновление одной из сторон меняет версию библиотеки, и скрипты перестают работать: слайдеры, формы, галереи.
• Миграция базы не завершилась. После обновления ядра WordPress предлагает «Обновить базу данных» — если пропустить шаг или оборвать процесс, сайт покажет ошибку подключения к базе.

Соблазн «не трогать, пока работает» понятен, но это худшая стратегия. Устаревшие плагины и ядро — вход номер один для взломщиков: уязвимости публикуются в открытом виде, и боты проверяют сайты на них круглосуточно. Регулярные обновления — часть базовых настроек безопасности WordPress, без которых бэкапы и сложные пароли не спасают.

Чтобы говорить на одном языке, разберёмся с версиями. Запись 6.8.1 означает: 6 — мажорная версия, 8 — минорная ветка, 1 — патч. Минорные обновления (6.8.0 → 6.8.1) — это исправления ошибок и дыр безопасности, они редко ломают сайты. Мажорные (6.8 → 6.9) приносят новый функционал и меняют внутренние API — именно с ними связаны риски. Отсюда главное правило: минорное — ставим сразу, мажорное — с подготовкой.

Что обновлять и в каком порядке

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

Компонент	Риск	Когда ставить	Комментарий
Переводы	Минимальный	Сразу	Файлы локализации не влияют на код сайта
Минорное ядро (6.8.x)	Низкий	Сразу, автоматически	Патчи безопасности и багфиксы
Плагины	Средний	По одному, после бэкапа	Смотреть список изменений, проверять сайт после каждого
Тема	Средний	После плагинов	Правки темы должны жить в дочерней теме, иначе потеряются
Мажорное ядро (6.9)	Высокий	Через 1–2 недели после релиза	Сначала на тестовой копии, потом на рабочем сайте

Порядок на самом сайте: копия → плагины → тема → ядро → сброс кэша. Ядро обновляем последним не случайно: плагины и тема должны быть готовы к новой версии, а не наоборот. В админке на странице «Обновления» WordPress честно предупреждает: «Протестировано с вашей версией WordPress» — если у плагина указана более ранняя версия, сначала обновите плагин или дождитесь патча разработчика.

Резервная копия перед обновлением: единственная страховка

Резервная копия превращает любую поломку из катастрофы в десятиминутную паузу. Копия нужна полная: файлы сайта (темы, плагины, загрузки) и база данных, где лежат записи, настройки и заказы. Обновление трогает и то, и другое, поэтому «скопировать только базу» — недостаточно.

Хостинг-бэкапы — подстраховка, но не замена: у них бывают ограничения по частоте и глубине хранения, а восстановление может требовать обращения в поддержку. Перед обновлением делайте собственную копию — инструменты и хранение разобраны в гайде по настройке резервного копирования WordPress. Минимальный вариант — плагин вроде UpdraftPlus: кнопка «создать копию» и готово. Если только собираете набор инструментов, пригодится подборка плагинов WordPress для начинающих — там UpdraftPlus есть.

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

# Полный дамп базы данных (файл появится в корне сайта)
wp db export backup-2026-09-10.sql

# Список плагинов с текущими версиями — сохраните перед обновлением
wp plugin list

# Проверка целостности файлов ядра
wp core verify-checksums

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

Обновление через админку: безопасный порядок действий

Кнопка «Обновить всё» — главный источник проблем: она ставит десяток обновлений одновременно, и если сайт сломался, вы не знаете, какой компонент виноват. Вместо неё — ручной порядок:

1. Откройте «Консоль → Обновления» и не выделяйте ничего в общем списке.
2. Обновите один плагин — критичный для сайта (форма, магазин, SEO).
3. Откройте сайт в соседней вкладке: главная, типовая внутренняя страница, форма. Работает — следующий плагин. Сломался — виновник уже известен.
4. После плагинов обновите тему, если для неё есть обновление.
5. Обновите ядро и подтвердите «Обновить базу данных», если WordPress её предложит.
6. Сбросьте кэш плагина кэширования — иначе вы и посетители будете видеть старые страницы. Как устроен кэш, разобрано в статье про настройку кэширования WordPress.

Во время обновления WordPress сам включает режим обслуживания: посетители видят страницу «Кратковременно недоступен в связи с плановым техобслуживанием», а в корне сайта появляется файл .maintenance. Обычно файл исчезает через минуту. Если сообщение залипло надолго — обновление оборвалось; удалите файл .maintenance из корня через файловый менеджер хостинга, и сайт вернётся.

Для долгих работ (миграция, крупное обновление WooCommerce) можно поставить свою заглушку с кодом 503 — он говорит поисковикам «это временно». Сниппет добавляется в functions.php дочерней темы WordPress, чтобы правки не потерялись при обновлении темы:

// Заглушка «Технические работы» для всех, кроме администраторов.
// Включать только на время работ и НЕ забыть удалить!
function ds_maintenance_mode() {
	if ( ! current_user_can( 'manage_options' ) ) {
		wp_die(
			'<h1>Технические работы</h1><p>Сайт обновляется. Вернитесь через 10–15 минут.</p>',
			'Обслуживание',
			array( 'response' => 503 )
		);
	}
}
add_action( 'init', 'ds_maintenance_mode' );

После работ сниппет убирают: проще всего закомментировать строку с add_action. Больше практичных приёмов для functions.php — в подборке полезных сниппетов для functions.php.

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

WP-CLI: обновление и откат из консоли

WP-CLI — официальная консоль WordPress: вы подключаетесь к серверу по SSH (у большинства хостингов она есть на тарифах выше минимального) и управляете сайтом командами. Механизм тот же, что у кнопок в админке, но без лимитов веб-скриптов: обновление не оборвётся по таймауту, даже если плагинов и записей много.

Базовый сценарий «копия сделана — обновляем всё»:

wp core update          # ядро до последней версии
wp core update-db       # миграция базы данных (после обновления ядра)
wp plugin update --all  # все плагины
wp theme update --all   # все темы
wp cache flush          # сброс кэша

Выборочное обновление и откаты:

# Какие плагины ждут обновления
wp plugin list --update=available

# Обновить только нужные плагины
wp plugin update woocommerce contact-form-7

# Откат плагина на конкретную версию
wp plugin install woocommerce --version=9.1.0 --force

# Откат ядра (только при наличии свежей копии!)
wp core update --version=6.7.2 --force

Флаг --force при установке старой версии нужен потому, что WordPress по умолчанию не «понижает» версии. Команда ставит указанный релиз поверх текущего — данные плагина при этом обычно сохраняются. Но после отката обязательно проверьте сайт: структура базы данных новой версии может отличаться от старой.

Автообновления: что включить, а что держать под ручным контролем

Из коробки WordPress автоматически ставит минорные обновления ядра — и правильно делает: это патчи безопасности, они должны появляться без вашего участия. Настройка живёт в wp-config.php и допускает три значения:

// 'minor' — только минорные обновления ядра (рекомендуется)
// true    — все обновления ядра, включая мажорные
// false   — полностью отключить автообновления ядра
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Для плагинов WordPress начиная с версии 5.6 даёт кнопку автообновления прямо в списке. Правило новичка: авто — для простых и независимых плагинов, вручную — для всего, от чего зависит бизнес. WooCommerce, плагин форм, SEO-плагин, LMS — обновляйте руками по схеме из раздела выше: у них сложные зависимости, и молчаливое ночное обновление может обернуться утренним сюрпризом в виде неработающей корзины.

Если хотите задать доверенные плагины кодом, WordPress даёт для этого фильтр:

// Автообновлять только перечисленные плагины, остальное — вручную
add_filter( 'auto_update_plugin', function ( $update, $item ) {
	$trusted = array( 'akismet', 'wp-super-cache' );
	return in_array( $item->slug, $trusted, true );
}, 10, 2 );

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

Если сайт сломался после обновления: план спасения

Сайт отдал белый экран или надпись «На сайте возникла критическая ошибка»? Спокойно: в большинстве случаев это один конкретный плагин, и чинится за 15 минут. Действуйте по порядку.

Шаг 1. Включите лог ошибок. WordPress не показывает ошибки посетителям (и правильно), но умеет писать их в файл. Добавьте в wp-config.php — ошибки появятся в wp-content/debug.log:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );      // писать ошибки в wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', false ); // не показывать ошибки посетителям

В логе будет строка вида PHP Fatal error: ... in /wp-content/plugins/imya-plagina/file.php on line 42 — виновник назван чёрным по белому.

Шаг 2. Отключите все плагины разом. Если админка тоже недоступна, зайдите в файловый менеджер хостинга и переименуйте папку wp-content/plugins в plugins_off — WordPress не найдёт плагины и деактивирует их, сайт поднимется. Верните папке прежнее имя и включайте плагины по одному, начиная с подозреваемого из лога. В консоли то же делает команда wp plugin deactivate --all.

Шаг 3. Сбросьте кэш. Если сайт работает, но выглядит сломанным — это кэш: плагина, CDN и браузера. Порядок сброса описан в разделе про кэширование выше.

Шаг 4. Откатите виновника. Команды из раздела про WP-CLI возвращают плагин или ядро на рабочую версию. Если консоли нет — скачайте прежний релиз плагина с wordpress.org и замените файлы плагина через файловый менеджер.

Шаг 5. Восстановите копию. Крайняя мера, когда ничего не помогло. Именно ради этого шага копия делается до обновления.

Типовые симптомы и быстрые решения сводим в таблицу:

Симптом	Вероятная причина	Быстрое решение
Белый экран или «критическая ошибка»	Фатальная ошибка PHP в плагине или теме	debug.log → отключить плагины → откат виновника
«Плановое техобслуживание» не исчезает	Обновление оборвалось, залип файл .maintenance	Удалить .maintenance из корня сайта
«Ошибка установки соединения с базой данных»	Миграция базы не завершилась	wp core update-db, при ошибке — восстановление из копии
Развалилась вёрстка, старые стили	Кэш плагина, CDN или браузера	Сброс кэша и обновление страницы с Ctrl+F5
Письма с форм перестали приходить	Обновление затронуло почтовый плагин	Проверить настройки SMTP-почты WordPress
Обновление обрывается, ошибка 503	Скрипт упёрся в лимиты хостинга	Обновлять по одному или через WP-CLI

Чек-лист проверки сайта после обновления

Обновление заканчивается не кнопкой «Готово», а проверкой. Пройдите по списку — это пять минут:

• Главная страница и типовая внутренняя (услуга, статья) — открываются, вёрстка на месте.
• Запись или товар — текст, картинки, комментарии.
• Формы: заявка реально уходит, письмо доходит до почты.
• Для магазинов — корзина и оформление заказа до последнего шага.
• Мобильная версия — меню открывается, ничего не наползает.
• Консоль браузера (F12 → Console) — нет красных ошибок JavaScript.
• Вход в админку и выход — авторизация работает.
• Версии на странице «Консоль → Обновления» соответствуют ожидаемым.

Последний быстрый тест — REST API: от него зависит редактор блоков и многие плагины. Откройте консоль браузера (F12) прямо на сайте и выполните:

fetch( '/wp-json/' )
	.then( r => { console.log( 'HTTP-статус:', r.status ); return r.json(); } )
	.then( d => console.log( 'REST API работает. Доступно:', d.namespaces.join( ', ' ) ) )
	.catch( e => console.error( 'REST API не отвечает:', e.message ) );

Если в консоли появился «HTTP-статус: 200» и список namespace — сайт после обновления жив, REST-маршруты на месте.

Частые вопросы об обновлении WordPress

Вывод

Обновление WordPress — не рутина, которую «надо бы», а часть безопасности и скорости сайта: свежие версии закрывают известные уязвимости и не тормозят админку. Рабочая схема на каждый день: резервная копия → плагины по одному → тема → ядро → сброс кэша → чек-лист проверки. Минорные патчи оставьте автоматическими, мажорные релизы ставьте с задержкой в одну-две недели — и всегда по схеме, а не кнопкой «Обновить всё».

Если обновлять некогда или страшно — это нормальная задача на аутсорс: посмотрите, что входит в поддержку сайта и сколько она стоит, или изучите наши услуги по разработке и поддержке сайтов. Примеры работ — в портфолио, практика по WordPress выходит в блоге delai-sait.ru. Чтобы передать обновления и мониторинг нам, напишите через форму контактов — настроим безопасную схему обновления под ваш сайт.