Journal шаблон… и почему это уже НЕ OpenCart, а Франкенштейн

Journal фактически не является «шаблоном» в классическом понимании, а отдельной платформой поверх Opencart (скорее уже мимикрия под Opencart). Они не просто делают theme/view, а:

- заменяют весь движок Opencart
- переписывают все контроллеры, модели и библиотеки
- добавляют собственный «framework» с мини-CMS
- интегрируют собственный рендеринг, кэширование, конфигурацию
- ломают стандартный lifecycle Opencart

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

Такие подходы типичны для крупных студий из Азии - делают максимальное количество функций в одном пакете, не заботясь о чистоте архитектуры и оптимизации скорости, и потом продают под английским юрлицом для лучшего доверия и более простого биллинга. Это объясняет, почему код Journal выглядит так, как выглядит, и почему они «прячутся» за Digital Atelier Limited в Великобритании.

Это уже не Opencart

Почему так сделали
продать «всё-в-одном» без зависимости от экосистемы

Как технически заменили движок
массовые OCMOD/VQmod патчи ядра + собственные контроллеры/модели вместо стандартных
собственный лоадер, конфиг и кэш-слой, перехватывающий Loader, Document, Response
замена движка шаблонов: свои рендеры/функции вместо чистого Twig/Template
глобальные события и prepend-логика, обходящие стандартный lifecycle OC
собственные библиотеки под Resource Manager (медиа, меню, блоки) поверх MVC-L

Последствия
несовместимость с обновлениями OC и модулями, опирающимися на ядро
неконтролируемая сложность, дублирование функций ядра, тяжёлые багфиксы
снижение производительности на крупных проектах из-за слоя поверх слоя, отсутствие реальной оптимизации скорости - это сплошное тормозило
vendor lock-in: вы зависите от Journal API, а не от Opencart

Как это быстро распознать
количество OCMOD > 100, большие патчи system/library/, system/engine/
наличие их «framework» директорий, собственных конфигов и рендеров
контроллеры ядра вызывают их фасады/хелперы вместо стандартных
модули «не из Journal» ломаются или требуют специнтеграции

Что делать, если уже стоит
Это уже «труба» к сожалению
не ставить на проекты с долгой жизнью и интеграциями
брать лёгкий theme + свои модули, держать ядро чистым
правило: ни один «шаблон» не должен заменять system/engine/* и system/library/*

Альтернатива
чистый OC + шаблоны нормальных разработчиков, которые можно кастомизировать собственным дизайном через CSS или изменениями ocmod Twig файлов шаблона, кастомные модули через Events/OCMOD с малыми патчами
Коротко: Journal намеренно подменил движок, чтобы быть платформой, а не темой. Архитектурно - это «анти-Opencart» и к тому же медленный монолит.

Ядро Opencart как раз одно из самых гибких среди бесплатных CMS.
У него есть:
события (Events) + OCMOD/VQmod
расширяемый Loader и Registry
собственный MVC-L слой (Model–View–Controller–Language)
Twig/Template на выбор
система layout-ов и позиций блоков

Благодаря этому можно менять практически всё, не переписывая движок. И именно поэтому серьёзные разработчики делают модули/темплейты как накладки: контроллер > событие > view, а не перетирают system/engine/*.

Journal не использует эту гибкость. Они просто вынесли себе собственный «движок» в catalog/controller/journal3/* и через массовые OCMOD патчи обошли Registry/Loader, чтобы подключать свой код напрямую. Это не «ограничение Opencart», а нежелание/неумение вписаться в его архитектуру. Они не использовали возможности ядра, а сделали переписывание - и получился Frankenstein.

Всё сводится не к технической необходимости, а к рынку и мотивации:
- быстрый результат для продаж
- минимум зависимости от сторонних модулей, но сделано «в лоб»
- английское юрлицо для доверия, большинство покупателей даже не смотрят на код
низкий уровень заказчика: 90% пользователей Journal не разработчики, ставят и думают, что это нормальный Opencart, проблемы проявляются через год-два...

Поэтому это выглядит как подстава, но для Journal это бизнес-модель: они продают коробку, которая выглядит как Opencart, но по факту собственная CMS. Техническое качество, долгосрочная совместимость и оптимизация скорости не их приоритет, приоритет — количество продаж.

Информация об этом есть, но в основном на форумах и в комментариях: «Journal heavily modifies the Opencart core, incompatible with many extensions». Это мелким шрифтом или в отзывах, большинство не читает.

Это сознательное решение авторов Journal. И пока пользователи платят, они не меняют подход.
Journal — это одна большая катастрофа.
Обходите это ... стороной

Покупайте проверенные шаблоны от украинских разработчиков

journal