Обновление WordPress ломает сайт чаще, чем хотелось бы: конфликт версий, устаревший код в теме, несовместимый плагин. Разбираем порядок безопасного обновления и способ откатиться, если что-то пошло не так.
Почему обновление WordPress может сломать сайт
Ядро WordPress, плагины и тема развиваются независимо друг от друга. Автор плагина может использовать функцию, которую разработчики ядра пометили устаревшей и удалили в новой версии, — сайт получит белый экран сразу после обновления. Тема, написанная под WordPress 6.0, не обязана работать без ошибок на WordPress 6.7.
Риск растёт, если на сайте установлено больше 15-20 плагинов или используется устаревшая версия PHP. Разница между версией PHP на сервере и минимальными требованиями нового плагина — частая причина ошибки 500 после обновления; диагностика такой ошибки описана в статье Белый экран и ошибка 500 в WordPress: как найти причину.
Подготовка: бэкап перед каждым обновлением
Правило без исключений: обновление без свежего бэкапа — это ставка, а не работа. Резервная копия должна включать файлы сайта и базу данных целиком, а не только папку с темой. Порядок создания и восстановления копии описан в статье WordPress бэкап: UpdraftPlus и ручной метод.
Перед запуском обновления проверьте дату последней резервной копии в панели плагина бэкапа. Если копии больше суток — сделайте новую вручную, не полагаясь на расписание.
Порядок обновления: плагины, тема, ядро
Обновляйте компоненты по очереди, а не разом через кнопку «Обновить всё»:
- Сначала плагины — по одному, с проверкой сайта после каждого.
- Затем дочерняя или основная тема.
- В последнюю очередь — ядро WordPress.
Такой порядок сужает поиск виновника до одного компонента, если сайт сломался. При обновлении сразу двадцати плагинов найти конфликт займёт часы; при обновлении по одному — минуты.
Обновление через WP-CLI на сервере
Из терминала обновление проходит быстрее и удобнее логируется:
# Посмотреть список плагинов с доступными обновлениями
wp plugin list --update=available
# Обновить один плагин
wp plugin update plugin-name
# Обновить ядро WordPress до последней версии
wp core update
Полный список команд для управления обновлениями и резервными копиями через терминал — в статье WP-CLI: управление WordPress из командной строки. Команда wp core update сама создаёт точку восстановления базы перед миграцией схемы, но файловый бэкап она не делает — его нужно готовить отдельно.
Как проверить сайт после обновления
Открывать боевой сайт сразу после обновления рискованно. Правильный порядок — прогнать обновление на staging-копии, а уже потом повторить его на продакшене; как поднять тестовую копию, описано в статье Staging сайт для WordPress: тестовая среда без риска.
После обновления проверьте минимум три вещи: главную страницу без ошибок в консоли браузера, форму обратной связи или корзину, если есть WooCommerce, и админку — заход под администратором и сохранение любой записи.
Откат: как вернуть предыдущую версию
Если после обновления сайт сломался, порядок действий такой:
| Что сломалось | Действие |
|---|---|
| Один плагин | Откатить плагин через архив версий или восстановить его файлы из бэкапа |
| Тема | Восстановить папку темы из резервной копии, ядро и плагины не трогать |
| Ядро WordPress | Восстановить базу данных и файлы целиком из бэкапа, сделанного перед обновлением |
Полный откат сайта из архива обычно быстрее, чем ручной подбор совместимой версии плагина. Проверочный список перед стартом каждого обновления:
- Свежий бэкап файлов и базы данных не старше суток.
- Обновление проверено на staging-копии.
- Компоненты обновляются по одному, не все сразу.
- После обновления проверены главная страница, форма и админка.