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 на середньому сервері
🇺🇦 Купуйте перевірені шаблони від українських розробників на форумі 🌻
Немає коментарів для відображення