OpenCart 3 или 4: обновляться ли и что сломается

Переходить на OpenCart 4 имеет смысл, если хостинг требует новую версию PHP, а магазин держится на небольшом числе модулей. Прямого пути с 3.0 на 4.x нет. Модули и тему для новой версии ищут заново или заказывают доработку под неё. Магазину с десятками кастомных модулей и правками ядра часто дешевле остаться на 3.0 и обновить только PHP. Ниже — таблица решения по восьми признакам и план перехода, если он выгоднее. Если разбираться самостоятельно некогда, поддержку магазинов на OpenCart и ocStore можно передать подрядчику и снять с себя выбор версии.

Когда переходить, когда оставаться

Три условия за переход: хостинг отключает поддержку PHP 8.1 и ниже, модулей меньше десяти, а тема стандартная или почти без правок. При таком наборе перенос обходится предсказуемо: аналоги модулей под 4.x чаще всего уже существуют, а тему можно взять готовую.

Три условия за то, чтобы остаться. Модулей больше двадцати, часть из них написана под заказ и аналогов под 4.x нет. Ядро правили напрямую, а не через модификаторы (переносимые патчи поверх немодифицированного кода). Магазин планируют закрыть или заменить новой разработкой в течение года — тогда миграция не окупится. Здесь выгоднее держать PHP в актуальной для 3.0.x версии и не трогать архитектуру.

Промежуточных вариантов тоже хватает. Часть владельцев переносит только каталог и заказы, а модули пересобирает поэтапно в течение нескольких месяцев. Часть держит рабочий магазин на 3.0.x и параллельно готовит копию на 4.x — до полной уверенности, что аналоги модулей закрывают все нужные функции. Спешить с полным переключением не обязательно. Тестовая копия может жить рядом с рабочим магазином неделями.

Что изменилось в OpenCart 4.x

OpenCart 4.0.0.0 поднял минимальные требования до PHP 8.1, а текущая линия 4.1.x проверяется на новых версиях PHP по релизам на GitHub (сверено 29.09.2026). Изменилась система расширений: модули 4.x ставятся и обновляются через отдельный установщик, а не копированием файлов поверх ядра, как в 3.0.x. Админка переработана — часть разделов объединили, поменялось расположение настроек оплаты и доставки. Шаблонизатор для тем остался Twig, но структура файлов темы другая: тема 3.0.x в 4.x не откроется без переноса.

Ветка 3.0.x тоже жива. Релиз 3.0.5.1 добавил патчи совместимости с новыми версиями PHP. Разработчики держат 3.0.x самостоятельной линией: новых функций там не добавляют, только фиксы безопасности и совместимости. Для владельца это значит: 3.0.x можно держать безопасной по PHP ещё несколько лет. Но функциональность заморожена на уровне 2020-х годов.

OpenCart, ocStore и русские сборки: в чём разница

ocStore — не отдельная CMS, а сборка на движке OpenCart, адаптированная под русскоязычную розницу: другой набор полей заказа, свои модули оплаты и доставки, правки в ядре под локальные требования. Обновляется она собственным темпом и с задержкой от основного проекта: по данным GitHub, последний релиз ocStore — ветка 3.0.4.1, тогда как официальный OpenCart уже на линии 4.1.x (сверено 29.09.2026). Прямого перехода ocStore на OpenCart 4 нет. Слишком много различий в ядре.

Если магазин работает на ocStore, первый шаг — выяснить, какая именно сборка установлена и какие правки внесены поверх неё. Версия OpenCart здесь не главное. Дальше вопрос звучит иначе: остаться на текущей сборке с патчами PHP или переезжать на чистый OpenCart 4 с миграцией данных вручную. По объёму работ второй путь ближе к новому магазину, чем к обновлению.

Таблица решения: остаться на 3.0.x или переходить на 4.x

Пройдите строки по очереди. Три и больше пунктов в столбце «переходить» — планируйте миграцию в квартал. Большинство в столбце «остаться» — обновляйте PHP и живите на 3.0.x дальше.

Считать баллы буквально не нужно. Два признака решают почти всё: версия PHP на хостинге и число модулей с правками ядра. Если хостинг ещё держит нужную версию PHP для 3.0.x, а модулей мало — остальные строки можно смотреть спокойно, без спешки. Если хостинг уже объявил дату отключения старых версий PHP — таблицу стоит пройти целиком в течение недели, а не откладывать на потом.

Что сломается при переходе

Модули. Автоматического апгрейда 3.0 → 4.x нет ни для одного модуля. Каждый ищут заново в каталоге расширений 4.x, покупают аналог или заказывают перенос логики.

Тема. Файлы шаблона 3.0.x несовместимы со структурой 4.x. Тему переносят вручную или берут готовую под новую версию и переносят в неё фирменные элементы.

SEO-адреса. Правила формирования ЧПУ (человекопонятных URL) в 4.x другие. Часть адресов товаров и категорий меняется, а старые ссылки из поиска и соцсетей без редиректа уводят в 404.

Модули фильтра. Фильтры каталога в 4.x работают через новую систему расширений, и старые настройки правил фильтрации не переносятся автоматически — их задают заново, заодно решая, какие фильтры открывать для поиска: настройка фильтров под SEO.

Обмен с 1С и склад. Модуль обмена товаров и остатков пишут под конкретную версию ядра. При переходе на 4.x старый модуль обмена магазина с 1С чаще всего переустанавливают или дорабатывают заново. Просто скопировать файлы не выйдет.

Платёжные модули. Эквайеры и СБП-провайдеры сертифицируют интеграции под конкретную версию движка. Модуль, работавший на 3.0.x, для 4.x проверяют заново у провайдера. Иногда это неделя переписки, иногда — месяц ожидания в очереди на сертификацию.

Письма и уведомления. Шаблоны транзакционных писем — о заказе, оплате, отгрузке — тоже переносят вручную. Формат хранения шаблонов в 4.x другой, автоматической конвертации нет. Без проверки этого шага письма могут перестать доходить сразу после запуска новой версии. Заметят это не сразу. Чаще всего — через жалобы покупателей.

План перехода на 4.x по шагам

1. Инвентаризация: список модулей, правок ядра и особенностей темы. Здесь же снимают проверенную копию магазина — без неё сравнивать «было / стало» не с чем.
2. Поиск аналогов модулей под 4.x или оценка доработки на заказ для тех, аналогов которым нет.
3. Тестовая копия на 4.x: разворачивается на отдельном домене или поддомене, в стороне от рабочего магазина.
4. Перенос данных: каталог, клиенты, история заказов, настройки доставки и оплаты — через штатный импорт или скриптом под структуру 4.x.
5. Проверка узких мест: оформление заказа целиком, расчёт доставки, применение промокодов, отправка писем.
6. Карта редиректов для адресов, которые поменялись при переходе — до переключения, не после.
7. Переключение в низкий сезон и мониторинг позиций и заказов две-четыре недели после запуска.

Каждый шаг стоит фиксировать письменно: что перенесено, что проверено, кто отвечает. Без такого протокола переход растягивается, а разбирательство после сбоя занимает больше времени, чем сама миграция. Отдельно стоит держать откат: рабочий магазин на 3.0.x не выключают, пока новая версия не отработала на реальных заказах хотя бы неделю.

Остаться на 3.0 или уйти с OpenCart: как жить безопасно

Оставаться на 3.0.x безопасно, если PHP держат на последней поддерживаемой для этой ветки версии и не правят файлы ядра напрямую. Патчи 3.0.5.x закрывают совместимость с новыми PHP, но не добавляют защиту сами по себе — обновления ставит кто-то регулярно, а не по случаю.

Вопрос «остаться на 3 или уйти с OpenCart» шире, чем номер версии. Иногда магазину нужна не миграция на 4.x, а смена платформы целиком. Здесь полезно прикинуть выбор CMS для магазина и сравнить стоимость владения разными движками. Затраты на переход внутри OpenCart — только часть сравнения.

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

Поддержка магазинов на OpenCart и ocStore на стороне Toimi устроена по уровням: технические обновления и исправления — от 15 000 ₽ в месяц, правка модулей и логики — от 30 000 ₽, новые функции и оптимизация — от 50 000 ₽ (сверено на странице 29.09.2026).