Обновление WordPress, OpenCart и MODX: когда обновлять и чем рискуете

Кнопка «Обновить» в админке выглядит безобидно, пока после неё не перестаёт работать корзина, не «уезжает» шаблон или не пропадают заказы из обмена с 1С. Обновление WordPress, OpenCart, MODX или Drupal — это не одна операция, а три разных по риску работы: патч безопасности внутри ветки, переход на новую мажорную версию и смена поколения движка, которая по сути является миграцией. Разберём, когда обновлять движок обязательно, чем рискуете в каждом случае и как пройти процесс без простоя.

Статья для владельцев сайтов и руководителей, у которых сайт работает на популярной CMS и давно не обновлялся. Про 1С-Битрикс есть отдельный разбор — как обновить ядро и модули Битрикса, здесь его не повторяем.

Зачем обновлять CMS и что будет, если не обновлять

Обновления закрывают уязвимости. Массовые взломы сайтов на WordPress, OpenCart и MODX чаще всего идут не через ядро, а через устаревшие плагины, модули и темы с опубликованными эксплойтами: боты сканируют интернет по версиям и заходят туда, где патч не поставлен. Типичные последствия — редиректы на чужие сайты, спам-страницы в индексе, веб-шеллы в каталоге загрузок, утечка базы клиентов.

Вторая причина — PHP. Хостинги отключают старые версии PHP, а старый движок на новом PHP не запускается. Получается замкнутый круг: сидеть на PHP 7.x небезопасно, а перейти на 8.x нельзя без обновления CMS и модулей. Чем дольше откладываете, тем больше разрыв и тем дороже его закрывать — это классический технический долг.

Общий алгоритм безопасного обновления любой CMS

Движки разные, но порядок работ один. Если хотя бы один шаг пропущен, обновление превращается в лотерею.

1. Инвентаризация. Версия ядра, PHP, MySQL, список плагинов и модулей с версиями, какие из них платные, какие правились вручную, есть ли изменения в файлах ядра.
2. Полный бэкап файлов и базы данных, сохранённый вне сервера. И проверка, что из него реально разворачивается рабочий сайт.
3. Тестовая копия на отдельном поддомене или сервере с той же версией PHP, закрытая от индексации и с отключёнными рассылками и оплатой.
4. Обновление на копии: сначала ядро, затем модули и тема, затем PHP. Каждую ошибку фиксируем и исправляем там же.
5. Проверка сценариев: каталог, поиск, фильтры, корзина, оформление заказа, оплата, формы, личный кабинет, обмен с 1С и CRM, письма, SEO-адреса, скорость.
6. Перенос на прод в часы минимальной нагрузки, со свежим бэкапом прямо перед выкладкой.
7. План отката: заранее известно, кто и за сколько минут вернёт прошлую версию, если что-то пошло не так.

Обновление WordPress: ядро, плагины, темы и PHP

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

Ядро и версии в 2026 году

Актуальная ветка — WordPress 7.x: версия 7.0 вышла 20 мая 2026 года (в июле вышел патч 7.0.2 с критической уязвимостью, который WordPress.org разослал принудительно), 7.1 — 19 августа, а 17 сентября — 7.1.1 с 11 исправлениями безопасности. В 7.0 минимальная версия PHP поднята до 7.4, рекомендуемая — 8.3. Сайты на PHP 7.2–7.3 обновление до 7.0 не получат и останутся на ветке 6.9. Для бизнеса это сигнал: если хостинг до сих пор на PHP 7.x, сначала переходите на 8.2–8.3, потом обновляйте ядро.

Автообновления: что включено, а что нет

Минорные обновления ядра (патчи безопасности) WordPress ставит сам по умолчанию. С версии 5.5 в админке появилась возможность включить автообновление для отдельных плагинов и тем, с 5.6 — и для мажорных версий ядра. Удобно для блога на пяти плагинах, опасно для магазина на WooCommerce: плагин обновится ночью, а о сломанной оплате вы узнаете от покупателя утром. Для коммерческих сайтов разумная схема — автопатчи ядра включены, плагины обновляются вручную по графику через тестовую копию, критичные уязвимости закрываются вне графика.

Плагины, темы и WooCommerce

• Плагины обновляются по одному, с проверкой после каждого. Пакетное «Обновить всё» на 25 плагинах не даёт понять, кто именно сломал сайт.
• Заброшенные плагины (без обновлений больше года или снятые с каталога WordPress.org) ищут замену заранее — через них чаще всего и взламывают.
• Правки в теме делают только в дочерней теме. Если разработчик правил файлы родительской темы напрямую, обновление их затрёт — сначала переносим правки в дочернюю.
• WooCommerce обновляет структуру базы и шаблоны: после апдейта проверяются корзина, оформление, платёжные модули (ЮKassa, СБП), переопределённые шаблоны в теме и обмен с 1С.

WP-CLI для обновлений

На своём сервере или VPS обновление удобнее делать через WP-CLI: wp core update, wp core update-db, wp plugin update имя-плагина, wp theme update. Это быстрее, не упирается в таймауты веб-интерфейса и легко встраивается в регламент с бэкапом до и после. Если после обновления сайт отдаёт белый экран, WordPress с версии 5.2 присылает администратору письмо со ссылкой на режим восстановления — через него можно отключить сломавший сайт плагин.

Обновление OpenCart: почему «обновить» часто значит «мигрировать»

С OpenCart ситуация принципиально другая. Внутри одной ветки обновление относительно безопасно, но между ветками 1.5, 2.x, 3.x и 4.x разработчики каждый раз меняли архитектуру, и модули с темами одной ветки на другой не работают.

Ветки OpenCart и их несовместимость

• 1.5.x и 2.x — шаблоны на .tpl, свои форматы модулей. Официально не поддерживаются, на современных версиях PHP без доработок не работают.
• 3.0.x — шаблоны на Twig, модули переехали в каталог extension, модификации через OCMOD. В августе 2026 вышла 3.0.5.1 с поддержкой PHP 8.5. Под эту ветку до сих пор написана основная масса модулей маркетплейса.
• 4.x — новая система расширений (каждое в своей папке), события вместо части модификаций, переработанная админка. Актуальная стабильная версия — 4.1.0.4 (11 августа 2026), тоже с поддержкой PHP 8.5.

Отсюда главный вывод: переход с 2.x на 3.x или с 3.x на 4.x — это перенос данных (товары, категории, клиенты, заказы, SEO-адреса) на чистую установку новой версии плюс подбор или переписывание каждого модуля и темы. Зашифрованные модули адаптировать нельзя — только покупать аналог под новую ветку.

ocStore и русские сборки

Многие российские магазины работают на ocStore — локализованной сборке OpenCart с русским языком, SEO-адресами и доработками под наш рынок. Она отстаёт от оригинала: последний релиз — 3.0.4.1 (октябрь 2025), ветки 4.x у ocStore нет, а часть модулей написана именно под неё. Перед обновлением важно точно определить, что стоит на сайте: чистый OpenCart, ocStore или сильно переделанная сборка, — от этого зависит, какие модули и обмен с 1С переживут переход.

Обновление MODX: Revolution 2.x, 3.x и Evolution

У MODX две разные линейки, и их часто путают. Revolution — основная ветка, её развивает команда MODX. Evolution — старая архитектура, которая живёт отдельно как Evolution CMS; из Evolution в Revolution нельзя «обновиться», только перенести контент и заново собрать шаблоны и сниппеты.

MODX Revolution 2.8 → 3.x

Актуальные версии на сентябрь 2026 — 3.2.4 (август 2026, закрыла несколько уязвимостей ветки 3.x) и 2.8.9 (июль 2026, вышла одновременно с 3.2.3 и закрыла одну и ту же уязвимость). Ветка 2.8 пока получает исправления безопасности, но официальной даты окончания поддержки нет, а все новые возможности появляются только в 3.x. MODX 3.2 требует PHP 8.1 и выше.

Что меняется при переходе на 3.x:

• ядро переведено на пространства имён и новую версию xPDO: собственные сниппеты и плагины, обращающиеся к классам ядра по старым именам, нужно проверить и частично переписать;
• дополнения (Extras) должны иметь версии под MODX 3 — часть популярных пакетов обновилась, часть заброшена и требует замены;
• обновление делается последовательно: сначала до последней 2.8.x, затем на 3.x, с проверкой после каждого шага;
• меняется интерфейс менеджера — контент-менеджерам понадобится короткое привыкание.

Для сайта с десятком стандартных дополнений переход обычно проходит за несколько рабочих дней. Для сайта с магазином на miniShop2 и десятками самописных сниппетов — это полноценный проект с аудитом кода.

Обновление Drupal: 7 уже без поддержки, 10 — до декабря 2026

У Drupal самый строгий и предсказуемый график поддержки, и сейчас он особенно важен.

• Drupal 7 — поддержка закончилась 5 января 2025 года. Переход на 10 или 11 — это миграция: новые шаблоны на Twig, другие модули, перенос данных через Migrate API. Фактически новый сайт с сохранением контента.
• Drupal 10 — поддержка заканчивается 9 декабря 2026 года, последняя минорная версия — 10.6. Переход на 11 — именно обновление: модуль Upgrade Status показывает несовместимый код, а большую часть устаревших вызовов исправляет Drupal Rector.
• Drupal 11 — актуальная ветка (11.4 вышла в начале июля 2026). В неделю 7 декабря 2026 года запланирован выпуск Drupal 12.

Joomla в этой статье подробно не разбираем: принцип тот же — старые ветки (3.x) без поддержки, а переход на актуальную версию требует замены шаблона и расширений.

Сравнение: что ломается при обновлении разных CMS

Как часто обновлять движок и модули

Рабочий регламент для коммерческого сайта выглядит так:

• критические патчи безопасности — в течение 1–3 дней после выхода, вне графика;
• плановые обновления плагинов и модулей — раз в 2–4 недели пакетом через тестовую копию;
• минорные версии ядра — в ближайший плановый цикл;
• мажорные версии — не в день выхода, а через 1–3 месяца, когда авторы ключевых модулей выпустят совместимые версии;
• версия PHP — раз в год-полтора, по мере окончания поддержки текущей.

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

Чего не делать при обновлении CMS

• Не обновлять прямо на рабочем сайте в разгар продаж — особенно магазин в пятницу вечером.
• Не нажимать «Обновить всё» для 20+ модулей разом.
• Не править файлы ядра CMS: любое следующее обновление их перезапишет, а правки потеряются.
• Не ставить модули из «слитых» архивов с форумов — в них регулярно находят вредоносный код.
• Не переключать PHP на хостинге до того, как проверена совместимость движка и модулей.
• Не удалять старую версию сайта сразу после выкладки — держите её, пока не проверены все сценарии и не прошла хотя бы неделя.

Когда обновление лучше доверить подрядчику

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

• движок не обновлялся больше двух лет или отстаёт на целую ветку (OpenCart 2.x, MODX 2.x на PHP 7, Drupal 7);
• сайт — интернет-магазин с онлайн-оплатой и обменом с 1С или CRM;
• в коде есть правки ядра, самописные модули или платные модули с шифрованием;
• прошлое обновление уже ломало сайт, а причину так и не нашли;
• сайт уже взламывали или в нём есть подозрительные файлы — сначала лечение и аудит, потом обновление.

Бюджет зависит от разрыва в версиях и количества доработок. Плановое обновление внутри ветки укладывается в часы работы, переход между ветками с адаптацией модулей оценивается как доработка сайта по смете после аудита. Для ориентира: ставка на разовые работы в АП-ИМ — от 2 500 ₽/час, а абонентская поддержка с регламентными обновлениями — от 50 000 ₽/мес; точная сумма зависит от движка, числа модулей и сценариев, которые нужно проверить. Для WordPress и WooCommerce есть отдельный формат — поддержка сайтов на WordPress с обновлениями через тестовую копию.

Чек-лист перед обновлением движка

• Известны текущие версии ядра, PHP, MySQL и всех модулей
• Выяснено, правились ли файлы ядра и родительской темы
• Для каждого ключевого модуля есть совместимая с новой версией сборка или замена
• Сделан полный бэкап файлов и базы вне сервера, проверено восстановление
• Развёрнута тестовая копия, закрытая от индексации, с отключёнными оплатой и рассылками
• Составлен список сценариев для проверки: заказ, оплата, формы, обмен с 1С, письма
• Выбрано окно для выкладки с минимальной нагрузкой
• Есть план отката и ответственный за него
• После выкладки проверены логи ошибок, скорость и индексация ключевых страниц

Патчи безопасности нужно ставить регулярно и быстро на любом движке. Мажорные обновления WordPress, MODX 2.8 → 3.x и Drupal 10 → 11 — это плановый проект с тестовой копией и проверкой сценариев. Переход OpenCart между ветками и уход с Drupal 7 или MODX Evolution — миграция, которую нужно оценивать как отдельную доработку. Чем дольше сайт не обновлялся, тем дороже каждый следующий шаг, поэтому дешевле всего держать движок в актуальной ветке постоянно.