Утро, когда хостинг написал «критическая уязвимость»
Задача: письмо, которое нельзя игнорировать
Однажды утром хостинг прислал предупреждение: в ядре WordPress найдена критическая уязвимость, сайт нужно срочно обновить.
Со стороны это выглядит как «нажмите кнопку Обновить». На деле перед нами были:
- WordPress 6.3.4 — а актуальная версия 7.0.4. Прыжок через целую эпоху изменений.
- 19 плагинов — формы, SEO, транслитерация адресов, карта этажей. Часть платная, без действующих лицензий.
- Авторская тема и поля ACF, на которых держатся шапка, карусель акций и каталоги.
- Живой сайт с посетителями каждый день.
Один неудачный плагин — и вместо сайта торгового центра посетитель увидит белый экран.
Поэтому правило №1 было простым: на боевом сайте не экспериментируем.
Как мы обновили сайт торгового центра «Глобал Молл» с WordPress 6.3.4 до 7.0.4 — и чуть не поверили, что сломали его раньше, чем начали
Заказчик
«Глобал Молл» — торговый центр в Москве: десятки магазинов, фудкорт, развлечения, акции и интерактивная схема этажей. Сайт — это витрина ТЦ. Сюда приходят, чтобы найти магазин, узнать часы работы и понять, как добраться.
Если сайт не открывается или показывает пустоту, посетитель просто идёт в другой торговый центр.
Поиск пути
План выглядел надёжно, как по учебнику:
- Полный бэкап боевого сайта: файлы и база данных, 678 МБ.
- Тестовая копия на том же хостинге.
- Прогон обновления на копии — и только потом обновление рабочего сайта.
Бэкап сделали. Копию развернули. Обновили ядро и плагины прямо на ней — ни одной ошибки. Мы уже почти выдохнули.
А потом открыли копию рядом с оригиналом.
Копия, которая не была копией
Картина получилась странной: визуально всё было на месте, но работало и выглядело совсем не так, как должно.
- Пропал верхний блок с адресом и графиком работы.
- Карусель акций превратилась в серый прямоугольник.
- Вместо аккуратного меню — свалка из всех страниц сайта подряд.
- «Магазины», «Акции», «Развлечения» открывались пустыми. Торговый центр без магазинов.
Обновление прошло «успешно». Результат выглядел так, будто сайт сломан. Считать тест пройденным было нельзя.
Версии, которые не сработали
Версия первая — кеш. Боевой сайт мог просто показывать старый закешированный вид. Проверили: признаков кеширования нет, страницы собираются заново на каждый запрос.
Версия вторая — меню не привязано к своим местам. Готовые меню нашлись. Привязали, меню вернулось. Но блок с адресом, карусель и каталоги остались пустыми.
Версия третья — потерялись настройки темы. Начали сверять поля ACF, опции, содержимое главной страницы. Данные в таблицах выглядели одинаково. От этого ситуация казалась совсем тупиковой: информация вроде бы есть, а сайт её не показывает.
Поворот сюжета
Развязка нашлась там, где никто не ждал, — в конфигурационном файле боевого сайта. Сайт был подключён к другой базе данных, не к той, из которой мы делали копию.
В аккаунте хостинга лежала заброшенная база с похожим названием: старая, давно не используемая, с устаревшей структурой. Вместо современных «Магазинов», «Акций» и «Развлечений» там хранился устаревший формат записей. Тестовую копию мы собрали из этого двойника.
Одна неверная точка отсчёта объяснила всё сразу: и пустую шапку, и серую карусель, и свалку вместо меню, и пустые каталоги.
Решение
1. Пересобрали копию из правильной базы. Главная страница, меню, карусель и разделы совпали с боевым сайтом один в один: 25 магазинов, акции, новости, фильтры по этажам и категориям.
2. Отработали обновление на копии заново, уже на корректных данных: ядро, плагины, темы.
3. Разобрали ложную тревогу с картой. На копии схема этажей показывала ошибку: ключ Яндекс.Карт привязан к домену боевого сайта, и на тестовом адресе иначе быть не могло. На боевом домене карта работает. Мы это проверили, а не понадеялись.
4. Обновили боевой сайт в проверенном порядке: плагины → ядро → темы. На время установки обновлений сайт кратковременно переходил в режим обслуживания.
5. Сознательно не трогали три платных плагина (ACF PRO, SearchWP, расширение All-in-One WP Migration). К уязвимости ядра они не относятся, а без лицензионного ключа их обновление всё равно недоступно. Это можно сделать отдельно, когда у заказчика появятся лицензии.
6. Проверили результат двумя независимыми способами: через панель WordPress и через служебный RSS-фид сайта, который выдаёт версию движка напрямую из установленных файлов. Оба показали 7.0.4.
7. Заказчику развернули рабочую копию: на время обновления мы закрыли её от индексации поисковиками, чтобы не создавать дубль сайта в выдаче, а после проверки аккуратно удалили вместе с базой, без «хвостов» на хостинге.
Результат
- Критическая уязвимость закрыта: ядро WordPress обновлено до актуальной версии 7.0.4.
- Обновлены 12 плагинов и 4 системные темы, в том числе плагины форм обратной связи и SEO.
- Контент не пострадал: магазины, акции, новости, схема этажей, карусель и формы работают так же, как до обновления.
- Полный бэкап сохранён на случай отката.
- Заказчик получил подробный отчёт по версиям и списку того, что намеренно не обновлялось и почему.
Чему нас научил этот проект
Самая опасная поломка — не та, что видна сразу, а красиво работающая копия не того сайта.
Поэтому теперь, прежде чем переносить что-либо, мы первым делом сверяем, к какой базе данных подключён боевой сайт, а не доверяем названиям на хостинге. И не считаем тест пройденным, пока копия не выглядит и не работает так же, как оригинал.
Услуги: поддержка сайта, обновление и безопасность WordPress.
ваш проект
такие работы