Journal шаблон ... і чому це вже НЕ опенкарт, а Франкінштейн

Journal фактично не є "шаблоном" у класичному розумінні, а окремою платформою поверх Opencart (скоріше вже мімікрія під Opencart). Вони не просто роблять theme/view, а:

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

Для європейської чи північноамериканської школи розробки це виглядає як архітектурна катастрофа, бо такий продукт практично не сумісний із апдейтами й не підтримує екосистему модулів. Але з комерційної точки зору це дає швидкий результат: покупець отримує "все в одному" й не розбирається, що там усередині.

Такі підходи типовi для великих студій із Азії - роблять максимальну кількість функцій у одному пакеті, не дбаючи про чистоту архітектури й оптимізацію швидкості, і потім продають під англійською юрособою для кращої довіри й простішого білінгу. Це пояснює, чому код 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-ів та позицій блоків

Через це можна змінити практично будь-що, не переписуючи engine. І саме тому серйозні розробники роблять модулі/темплейти як накладки: контролер > подія > 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