Journal template ... and why this is already NOT OpenCart but Frankenstein

Journal is not actually a “template” in the classical sense but a separate platform on top of Opencart (more like mimicking Opencart). They don’t just make theme/view, they:

- replace the entire engine of Opencart
- rewrite all controllers, models and libraries
- add their own “framework” with a mini-CMS
- integrate their own rendering, caching, configuration
- break the standard Opencart lifecycle

For a European or North American development school this looks like an architectural disaster, because such a product is practically incompatible with updates and does not support the module ecosystem. But from a commercial point of view it delivers quick results: the buyer gets “all-in-one” and does not look inside.

Such approaches are typical for large studios in Asia - they pack the maximum number of features into one package without caring about clean architecture or speed optimization, and then sell under a British legal entity for greater trust and simpler billing. This explains why Journal’s code looks the way it does and why they “hide” behind Digital Atelier Limited in the UK.

This is no longer Opencart

Why they did it
to sell “all-in-one” without depending on the ecosystem

How they technically replaced the engine
massive OCMOD/VQmod patches to the core + their own controllers/models instead of standard ones
their own loader, config and cache layer intercepting Loader, Document, Response
replacement of the template engine: their own renderers/functions instead of pure Twig/Template
global events and prepend logic bypassing the standard OC lifecycle
their own libraries for Resource Manager (media, menus, blocks) on top of MVC-L

Consequences
incompatibility with OC updates and modules relying on the core
uncontrolled complexity, duplication of core functions, heavy bug fixes
performance degradation on large projects due to layer upon layer, no real speed optimization - it’s a total slowdown
vendor lock-in: you depend on the Journal API, not on Opencart

How to recognize it quickly
number of OCMOD > 100, large patches to system/library/, system/engine/
presence of their “framework” directories, custom configs and renderers
core controllers call their facades/helpers instead of standard ones
non-Journal modules break or require special integration

What to do if it’s already installed
It’s already a mess unfortunately
do not use for projects with long life and integrations
use a lightweight theme + your own modules, keep the core clean
rule: no “template” should replace system/engine/* and system/library/*

Alternative
clean OC + templates from normal developers which you can customize with your own design via CSS or ocmod Twig file changes, custom modules via Events/OCMOD with minimal patches
In short: Journal deliberately replaced the engine to be a platform rather than a theme. Architecturally - it’s “anti-Opencart” and also a slow monolith.

The Opencart core itself is one of the most flexible among free CMS.
It has:
Events + OCMOD/VQmod
an extendable Loader and Registry
its own MVC-L layer (Model–View–Controller–Language)
Twig/Template support
a system of layouts and block positions

This allows you to change almost anything without rewriting the engine. And that’s why serious developers build modules/templates as overlays: controller > event > view, not overwriting system/engine/*.

Journal does not use this flexibility. They simply moved their own “engine” into catalog/controller/journal3/* and through massive OCMOD patches bypassed the Registry/Loader to hook their code directly. This is not an “Opencart limitation” but an unwillingness/inability to fit into its architecture. They didn’t use the core’s capabilities but rewrote it - and created a Frankenstein.

This all boils down not to technical necessity but to market and motivation:
- quick result for sales
- minimal dependence on third-party modules but done “head-on”
- a British legal entity for trust, most buyers don’t even look at the code
low customer level: 90% of Journal users are not developers, they install it and think it’s normal Opencart, problems appear after a year or two...

So it looks like a trap, but for Journal it’s a business model: they sell a box that looks like Opencart, but is actually their own CMS. Technical quality, long-term compatibility and speed optimization are not their priority, the priority is the number of sales.

Information about this exists but mainly on forums and in comments: “Journal heavily modifies the Opencart core, incompatible with many extensions.” It’s in small print or reviews, most people don’t read it.

This is a conscious decision by the Journal authors. And as long as users pay, they don’t change their approach.
Journal is one big disaster.
Avoid this stuff

Buy verified templates from Ukrainian developers

journal