The future of Opencart - Suggestions on maturity, roadmap, and ecosystem #15300

First and foremost, there is a critical need to bring order to the development and versioning process.

* Branch Management: Currently, development involving backward-incompatible changes and essential bug fixes happens within the same branch. This makes it impossible to pull necessary fixes without inheriting unstable architectural changes.

* Versioning Inconsistency: Minor versions (like 4.1.0.3) should theoretically focus on bug fixes relative to the 4.1.0.0 baseline. Instead, they introduce backward-incompatible changes—such as the modification of product fields (SKU, UPC, EAN, JAN, ISBN, MPN) and some refactoring.

This approach makes maintaining projects and extensions extremely difficult. Even if OCMOD were to be fully reintroduced, the heavy fragmentation of the 4.x.x branch would lead to massive confusion and compatibility issues.

I fully agree with you. We need a stable 4.1.x.x branch, and any new features, such as the headless design, etc, should go into a separate development branch for a future OC 4.2.x.x series.

I fully agree with you. We need a stable 4.1.x.x branch, and any new features, such as the headless design, etc, should go into a separate development branch for a future OC 4.2.x.x series.

To be honest, I don't see the rationale behind introducing Headless Design into OpenCart's core.
It doesn't seem to offer any real advantages here; instead, it creates a host of new problems:

Niche Use Case: Headless Design is primarily beneficial for projects focused on native mobile apps (iOS, Android). Even then, it can be achieved without forcing it into the core — simply by providing a robust API. Ideally, such an API should exist as an optional extension: those who need it can install it, while the majority won't be burdened by it.

SEO Complications: It introduces massive hurdles for SEO.

Redundancy: To solve the SEO issues, we are forced to implement Server-Side Rendering (SSR). What is the gain here? We are essentially removing the existing, working rendering system only to replace it with a new one that brings its own set of problems.

Complexity vs. Simplicity: OpenCart's greatest strength has always been its relative simplicity. Overcomplicating the core and creating unnecessary confusion will only drive away third-party developers.

Niche Use Case: Headless Design is primarily beneficial for projects focused on native mobile apps (iOS, Android). Even then, it can be achieved without forcing it into the core — simply by providing a robust API. Ideally, such an API should exist as an optional extension: those who need it can install it, while the majority won't be burdened by it.

I think OC headless design is meant to mitigate bots attacks etc. using server CPU and resources.. it will still be a self contained system with front end etc. I think it's a good approach, probably not the only one.

Complexity vs. Simplicity: OpenCart's greatest strength has always been its relative simplicity. Overcomplicating the core and creating unnecessary confusion will only drive away third-party developers.

I think third-party developers who relied on simplicity, like simple plugins, will have a hard time in the AI era, regardless of OC’s core complexity.

I fully agree with all the points raised.

It really makes sense to make better use of versioning and branches. There is a dev branch, but it seems to be unused and outdated; everything appears to be done in the master (main) branch.

New features should only start after we have a stable version, or they should be developed in another branch, such as feature branches.

Regarding OC headless, I also didn’t really understand the necessity. It is something more complex that involves many changes. It might be better to focus on building a solid API with cache in front of it plus rate limiting, and that would be enough. This would be more useful for all types of use cases, and anyone who wants to build a frontend consuming the API could simply do so.

Another issue is Apps/Plugins that modify the theme — how would they work? I imagine they would stop functioning.

I've tried to keep up with OpenCart 4.x development, and it's impossible to find a working version.

really??? what's wrong with OC3??

I fully agree with all the points raised.

It really makes sense to make better use of versioning and branches. There is a dev branch, but it seems to be unused and outdated; everything appears to be done in the master (main) branch.

New features should only start after we have a stable version, or they should be developed in another branch, such as feature branches.

Regarding OC headless, I also didn’t really understand the necessity. It is something more complex that involves many changes. It might be better to focus on building a solid API with cache in front of it plus rate limiting, and that would be enough. This would be more useful for all types of use cases, and anyone who wants to build a frontend consuming the API could simply do so.

Another issue is Apps/Plugins that modify the theme — how would they work? I imagine they would stop functioning.

If you are campaigning for OC3, then what are you doing in THIS thread, where we are talking about the development of OC4?

I may have misunderstood then if this this is about OC4 only... I understood it was about OC future.
ahahah no associations to OC here. As I said before, if it were up to me, I wouldn't have added Twig to the core at all.
Honestly, I did not understand the benefits of OC4 over OC3?
from an user's point of view, my thinking is: why bother with OC4 when OC3 already does everything OC4 does? The few extra features added in OC4 are too basic to be used as they are in my view.

Honestly, I did not understand the benefits of OC4 over OC3?

1. Bootstrap 5 over long ago outdated BS3
2. Extensions in a separate folder. This is much cleaner and easier to maintain and update than a mess of files in admin and catalog folders

For me these are the key features why I have moved my projects to OC4.

But, as everyone mentioned and I agree with this, the OC4 development turned into an uncontrolled experiment with no stable versions and function breaking useless features no one asked for with every minor release. And this lasts for many years.

I am using my own Frankenstein built somewhere between 4.1.0.0 and 4.1.0.1.

1. Bootstrap 5 over long ago outdated BS3

Agree, I bought one of these templates and it replaced bootstrap 3 with BS5
https://www.opencart.com/index.php?route=marketplace/extension&filter_member=octemplates

2. Extensions in a separate folder. This is much cleaner and easier to maintain and update than a mess of files in admin and catalog folders

Understood. From a dev point of view this is helpful..

I think we’re mostly on the same page. However I also believe that for an open-source system to succeed, it needs to aim for broad adoption, which means catering to a variety of use cases, including payment systems, shipping systems, etc. Perhaps these could be shipped as separate packages.

I was thinking more along these lines:

• SEO is mostly fine; the major missing feature is multiple URLs for the same product/category. It's simple to fix—so why not have that in the core? third-party modules can still add other features like bulk editing, automation etc.
• Filters: only one filter works at a time. It's easy to fix—so why isn’t this part of the core? third-party modules can address style, automation of filters, availability of filters in different pages, etc.

I agree that ERP, Marketing, automation etc. are big beasts which shouldn't be part of the core. I think there is a lot of scope for third-party developers to expand on this through modules and extensions. That would be more useful than 100 different extension $10-$100 all dealing with SEO...

I suppose a lot can be said about Wordpress/Woocommerce. I hope OpenCart doesn't become like that, and by that, I mean from a user's point of view, in terms of usability and backend workflow. I tried it few times and to me it feels still a blog platform on steroids = frankenstein back-end.

Regarding headless OpenCart, I don’t see it mainly as a protection measure. Even an API can be attacked — in fact, that’s often where attackers aim, not the visual frontend. For example, one client experienced login attacks, and the part that suffered was the Rate Limit itself because it depended on the database to check and validate requests. To mitigate this, it’s better to have a good WAF, rate-limit rules in Nginx, rate-limit logic in the store itself (preferably with Redis in front), and similar protections. Otherwise the database can easily reach “too many connections” or even crash, even on large dedicated servers.

This seems complicated for me. Does that requires root access to the VPS?
That said, I'd imagine Daniel must have had his reasons and most certainly more information than me when he decided to use Nunjucks for OC moving forward

@beipink

Agree, I bought one of these templates and it replaced bootstrap 3 with BS5

Yes, you can buy or create your own BS5 template. But none of the existing OC3 extensions will be compatible with it. You will have to adapt every extension template to BS5 classes.
BS5 has much better grid control, more lightweight, better UI tools, which is useful for admin area too. But OC3 customers and developers are stuck with BS3 released back in 2013.

Understood. From a dev point of view this is helpful..

With such an approach OC 1.4, or ZenCart 1.2 are fine too, as the customers do not care what is under the hood unless the store works. It's always the fidgety devs who bother about the outdated code and new tools :)

Excellent points, I agree with all of them.

In many cases, less is more, especially because if things become too complicated, it changes the target audience.

People use OpenCart because of its speed, ease of use, maturity, simplicity to modify, plugins/apps ecosystem, conversion efficiency, security, low resource consumption, and minimal or almost zero external dependencies, among other reasons. Today it is the only e-commerce platform that truly focuses on having a solid core and foundation. If you look at the competitors, most of them perform worse in terms of performance, simplicity, ease of modification, and of course server resource usage.

And as you mentioned, it can even become harder to maintain if the core grows too much with many features that only serve 1–5% of users.

Anyone who needs more specific features can simply use plugins/apps or build something custom. That is exactly why there is such a large ecosystem around OpenCart. After all, if the platform already included everything and satisfied 100% of user needs, why would there even be a Plugin Marketplace? The main source that sustains OpenCart and the professionals who work with it would not exist. And even then, built-in features would likely still be inferior to dedicated plugins that focus solely on solving a specific problem.

Hi @danielkerr ,

Regarding the idea of basically having a static store, generating the HTML, CSS, and so on, it seems interesting, but I do not understand what the actual benefit of this would be for OpenCart at the moment.

Wouldn’t this increase complexity? Because today OpenCart is basically a Controller that loads the Models and calls the View that uses Twig, processes the PHP, and builds the final HTML in cache, and that is it. Wouldn’t it be enough to cache the page itself to avoid database calls and use Redis RDI to update them automatically in Redis, at least for the parts that do not require login, such as Home, Categories, Products, and so on?

From what I understand, would the HTML be calling the APIs via JS, is that it? Or is the idea that the HTML would already come with the complete generated data?

I had this in my legacy e-commerce project. We built the whole view using Nuxt (Vue.js) and depended on a connected Node.js server, something like Koa.js or Express.js. I preferred to remove all of that and go back to the good old Twig, and that was it. I noticed it became slower as the project grew, because it kind of built the whole site application instead of loading just one page. I believe nowadays this process must be better, but for example, if our project had 5MB, then 5MB would be loaded no matter which page was accessed. Not to mention the serious dependency issues with Node.js (JS); the node_modules folder becomes huge and can easily break, or at least that used to be common.

Now, regarding OpenCart, I think the biggest negative point is how Plugins/Apps that modify the visual side would work. Would it still be possible to use OCMOD? For example, how would we add a “Notify Me” feature on the Product page, installment information, an extra tab, and other features? Today we do this easily with OCMOD without touching a single line of the original code, which is essential for a good plugin/app. And wouldn’t this more radical change break many Plugins/Apps?

I would find it better if the focus were on making OpenCart 4 production-ready, more mature, and only after that introducing more complex changes that could change everything. From what I understand, with SSR the servers would probably need to have Node.js running, which could increase complexity and add yet another dependency.

Now, if only static files are generated without API calls, then it may be interesting, but then I wonder: why not simply focus on building a great API plus database optimization with indexes and more use of cache? Many calls in OpenCart, or almost all of them, could easily come from Redis cache or some other caching layer.

Could it also be that this SSR feature would be better as a separate plugin, so whoever wants it can use it, and whoever does not can keep the standard model with Twig?

im moving to a SSR version where the bulk of the code is in html and javascript. the advantages are less updates required becausd of a new version of php coming out. i can get the full front of the site as just static html, css and js.

I don't quite understand. Most pages will still have dynamic content from variables to be dynamically generated with values and then to be presented as part of the content in the final HTML. I can understand that Symfony Twig isn't the ideal rendering engine, it basically generates PHP caches, which then have to to processed again by PHP to generated the final HTML.

I can understand that a CSR approach might be useful for certain scenarios, and for this a useful server API should be available for retrieving data such as product details, categories, info contents etc. But that is no reason to give up or radically modify the current MVCL structure of OpenCart. Add CSR as a separate feature!

OpenCart’s methods and technologies work. There are even stores running on OpenCart 2.3 that are happy with what it offers and what they can achieve with it.

It is only necessary to keep PHP and the other technologies updated to current versions. I do not think it is necessary to follow every trend. For example, Node.js (JS) was a trend not long ago, but it did not even come close to overshadowing PHP, which still powers more than 70% of the Web today.

OpenCart has its own internal MVC micro framework with support for libraries and language files. Its structure is simple, and anyone who knows PHP can understand it and start improving it within a few hours. This is different from e-commerce platforms that adopted full-stack frameworks such as Symfony, which is also good, but heavier and more complex, requiring more study and knowledge from whoever is going to work with it.

The only thing I would maybe recommend is a routing system in front of the controller, mainly for creating APIs. But for that, a good ready-made and lightweight library could be used, or even just improving the controller itself so it can define whether a route is POST, GET, and so on, which would already be a useful feature for building APIs.

For SQL, perhaps using PDO prepared statements, making PDO the default, would be a good idea. It could even use ready-made libraries that handle drivers and similar concerns, such as Doctrine DBAL (Database Abstraction Layer), which would keep queries close to how they are today without being as heavy as an ORM, or something simpler like Medoo.

In an older 2.3 store, what we changed the most was optimizing the database with indexes and putting Redis cache in front of everything possible, and performance improved dramatically. It has high demand, with peaks of online users and a high volume of orders, around 5–10 thousand or more per day. If I remove the indexes, its 16-core CPU is basically consumed immediately. With indexes, overall usage stays below 1 core, and sometimes 2, even while running many heavy background tasks using Cron Jobs.

What I miss most in it is Twig, which exists in version 3 and which we will probably migrate to, along with some new features from version 3 and of course version 4 as well. Unfortunately, we still cannot use version 4, because the focus of this store is maximum stability.

The issue with OpenCart today is not its technologies. In reality, the end customer wants a good store that is easy to use, customize, and maintain. If OpenCart changes its focus too much, it ends up moving into a different kind of competition, more like Magento, which is aimed more at large and huge stores and therefore can become heavy and bloated. I believe OpenCart’s main focus is small to medium-sized stores that sell anywhere from 1 order per day to 10–20 thousand or more orders per day.

The biggest issue today is that OpenCart’s main version is not the most suitable, recommended, or current one. Basically, even today OpenCart 3 clearly stands out over OpenCart 4, even though version 4 has new features. In e-commerce, the main priorities are stability, maturity, and simplicity, at least for OpenCart’s core audience. For example, my main client does not care at all that OpenCart 4 has a blog or a new Checkout, especially because that can be handled with a CMS and a custom checkout or by using an existing plugin. But having bugs in Registration or Orders would be unacceptable for them, because that would affect sales, as would problems with Login due to attacks or any other similar issue.

its not high end technology. i have just been following an old and outdated method.

OpenCart 3.0.x.x , and 4.1.0.3, is an example of a platform that already uses Server-Side Rendering (SSR). The server processes the requested data and generates the full HTML for a page before sending it to your browser. It uses the Model-View-Controller (MVC) pattern. The "View" part of this pattern is rendered on the server using the Twig template engine to produce the final HTML seen by the user. Because the server delivers a fully rendered page, search engine crawlers can easily "read" and index the content, which is a primary advantage of SSR.

So what exactly is the point of creating a new SSR? I could understand adding a CSR which might have some benefits for certain scenarios, and for this a better server API could become useful or needed. But there is no need to radically change the whole of OpenCart again!

I honestly don’t know any developers who rely on the native OpenCart CMS mechanism

Please do not speak for all developers :)
Having native blog system is awesome.

The fact that many customers use different blog extensions only proves the point that OC requires Blog/CMS system in the core.
The developers now may use default OC tables to store data. It will be easier to migrate between various extensions, themes and OC versions when the blog data is stored in same tables and format.

The developers now may use default OC tables to store data. It will be easier to migrate between various extensions, themes and OC versions when the blog data is stored in same tables and format.

In theory, this is, of course, good.
But in practice, it is dangerous to rely on something that may suddenly change in a minor version; it is safer to have something of your own.

dangerous to rely on something that may suddenly change in a minor version

This should never happen in the minor version. Sigh 😏
If you try to backup everything that can be changed, you may come up too far.

OC 3.0.5.0 would be the best stable choice right now.

1. It supports PHP 8.4
2. Got all possible latest extensions for it
3. Still supported

So you definitely will have no problems with it the next 2-3 years. Maybe even more.

The main problem we are discussing here - there is no roadmap, no release plan, no estimates.
Nobody knows how long OC3 will be supported.
Nobody knows when next stable OC4 will be released and what breaking changes it will bring.
Nobody knows where OC is moving 😮‍💨

@stalker780 Thank you very much for your answer. 👍

As you suggest I will most likely end up migrating to OC 3.0.5.0, as it currently seems like the easier path for migration and stabilization around the features we actually need.

I’m aware that this discussion is mainly about the lack of a clear roadmap, future plans, or estimates. What I personally find interesting is that many open-source projects have recently started moving faster thanks to AI assistance with bug fixes and feature development. I’m a bit surprised that this hasn’t happened here yet for a project like OpenCart, and that there is still relatively little communication about its future direction.

From what I’ve read in this discussion, I don’t think there is necessarily a strong need for a new major version every few months. Many store owners customize their OpenCart installations anyway.

What people seem to be looking for the most is simply a clearly communicated “stable version” — a version where things that worked before continue to work and where the ecosystem (extensions, modules, integrations) can rely on long-term stability.

At the moment, that feeling of stability and clarity seems to be what is missing the most.

I recommend version 3.0.5.0.
I'm even creating a store from scratch for the company, which currently uses a store built from scratch in Phalcon, something I greatly regret, but at the time Opencart didn't even have a responsive theme; it was version 1.5.

I'm going with 3.0.5.0 because of the maturity of Opencart 3 and because it has everything I need, in addition to the plugins/apps I already have ready, since we work with that. Opencart 4 years after its release, we haven't updated a single plugin because, in my opinion, it's not ready for production, and curiously, version 3 is newer than version 4, haha.

To give you an idea, I think it was just one client who asked if an improvement X had support for Opencart 4, and I was even curious that he's using it in production.

Opencart 3 should easily have another 2-3 years of life left, especially with PHP 8 support.

You like adventure, huh? But I'm surprised you managed to get it working without major adjustments.

Here, whenever I tested it, there was an obvious error in the Checkout or Registration that prevented any order from being finalized. I'm now switching to Opencart 3.0.5.0, let's see in 1-2 years, maybe a truly functional Opencart 4 will finally come out, or even a 5 based on Opencart 3.

they must use their opensearch(elasticsearch) to filter category products and search millions of products. a normal database like mysql cannot handle it, no matter how much you optimize. so leave it to the third-party extension.
all you need to do is to optimize and speed up the code and faster select from database.
maybe the seo_url key and value can be conbine into query again,because select one is faster than two even uses union index.

SSR for products may be useless if they have thousands of products, it will produce thousands of files, not worth it, fulltext search engine
like opensearch, elasticseach, manticoresearch etc can handle it easily and lightning fast.
but it is good for small data, such as template, translation, store, currency, language, store settings, tax, weight, length, country etc. such tables are small data and quite stable, so we don't need to select from database each time.

SSR for products may be useless if they have thousands of products, it will produce thousands of files, not worth it, fulltext search engine like opensearch, elasticseach, manticoresearch etc can handle it easily and lightning fast. but it is good for small data, such as template, translation, store, currency, language, store settings, tax, weight, length, country etc. such tables are small data and quite stable, so we don't need to select from database each time.

i can do it fully with html, css, javascript, and JSON. people will be able to upload stores to anywhere that can host html. JSON data can be on a sperate server if to large. all post requests will go back to one API.

JSON product data like category, manufacturer, filter, tag will just be filled with product ID's.

path-1_1.json
[1,2,4,5, 6, 7, 8, 9, 10, 11, 20, 30, 40, 50, 60]

filter-1.json
[1,2,4,60]

filter-2.json
[1,2]

product list

product-1.json
product-2.json

this can be done by those search engines, too and they are professional and lightning fast and can get the data anywhere from one place through http api request.
i think you should focus on the site speed and release a stable one

It can be indexed by databases like MariaDB/MySQL or specialized search databases like Meilisearch, TypeSense, and similar ones.

Basically, the data is sent to them for querying, but the source of truth will always be the main database, such as the store's MariaDB.

I'm creating a search system and will probably use TypeSense, but in general, if you want to keep MariaDB and similar databases, replacing the Like %% with Full Text Search would be a significant improvement; in fact, a plugin I created does exactly that.

In my opinion the current 4.1.0.3 should move to a separate branch where 4.1.x.x will be updated only for fixes to get stability.
Where several moderators can push fixes and prepare releases if Daniel have no time to do this.
Same as this happens with 3.0 now.

Make the master branch experimental alpha playground and update it to 4.2 or 5.0 major version as it got too many core changes compared to 4.0 and 4.1.

But it is up to Daniel, he is the owner of this repository. Looks like he does not care of OC users and developers much.

I agree with @stalker780. It would make sense for 4.1.0.3 to move to a separate 4.1.x maintenance branch, where updates focus only on fixes and stability. That way several moderators could contribute fixes and help prepare releases if Daniel doesn’t have time, similar to how the 3.0 branch is currently handled.

Meanwhile, the master branch could serve as an experimental playground for bigger changes and be moved to something like 4.2 or even 5.0, since it already seems to diverge quite a lot from 4.0/4.1 in terms of core changes.

Of course, in the end it’s Daniel’s repository and his decision how to manage it, but a structure like this could help both users and developers by separating stable maintenance from experimental development.

I agree, a separate branch focused on making Opencart 4 stable, or at least as functional as possible, without focusing on new features that it already has plenty of.

Now, the main branch shouldn't be focused on new features; it could have a features branch for new features, a dev branch for more active development, and the main branch after testing and so on, taking changes from dev and features, something like that.

The problem is that today it seems everything is in the main branch, mixing bug fixes with new features that end up causing more errors, and so on.

What I see is a lack of testing. I've been commenting on this for years; it seems like a new version of Opencart 4 is released without any testing. Even in development, it's always good to test to avoid accumulating too many bugs and complicating the production version.

• Automating tests
• Visual testing is super simple to do using a CLI in Playwright and similar programs that takes screenshots, validates each page with the expected return, performs performance tests, etc.
• There's also Pest PHP.
• And of course, human testing is also important. It doesn't hurt to place an order and see if it was captured correctly. It's a super simple test, or you can automate it as I mentioned above.

E-commerce is about stability and maturity; too many features are left to plugins, apps, and the like.

Opencart already has plenty of features to handle and manage. If it continues to grow in features, Opencart will become like Magento, but Magento focuses on giant stores, while Opencart focuses on small to medium-sized stores, even though it can handle any size store because it's lightweight and performs well—in fact, it's the best performing, especially if you prioritize indexing and caching.

I understand the desire to focus on features, etc., but I think it's better to fork or create a new project from scratch and focus on Opencart's stability, keeping it up-to-date with technologies, but not on the hype surrounding JS and similar things that don't make any logical sense.

@danielkerr @felipoantonoff @stalker780 Hey everyone, I’ve opened a PR to roll back to version 4.1.0.3 because the latest changes on master are causing issues and affecting stability. This rollback should restore a working state while we investigate the problems further.

Why return?
Wouldn't it be easier to create a branch based on 4.1.0.3?

@danielkerr @felipoantonoff @stalker780 Hey everyone, I’ve opened a PR to roll back to version 4.1.0.3 because the latest changes on master are causing issues and affecting stability. This rollback should restore a working state while we investigate the problems further.

Why return? Wouldn't it be easier to create a branch based on 4.1.0.3?

I rolled it back to 4.1.0.3 because this is the latest stable version in the 4.x.x line. The idea is to continue development and stabilization from there, building on a stable base.

The master branch will likely continue development towards version 5.x.

I rolled it back to 4.1.0.3 because this is the latest stable version in the 4.x.x line. The idea is to continue development and stabilization from there, building on a stable base.

You're doing it wrong and you're only cluttering up your commit history.

The 4.x.x.x branch was created incorrectly in the first place. While there is nothing in it yet, it is easier to delete it and create it again, based on the 4.1.0.3 tag. I provided 2 instructions above on how to do this correctly.

You're doing it wrong and you're only cluttering up your commit history.

The 4.x.x.x branch was created incorrectly in the first place. While there is nothing in it yet, it is easier to delete it and create it again, based on the 4.1.0.3 tag. I provided 2 instructions above on how to do this correctly.

Okay, I agree. I just wanted to help make the revert happen faster — I’m aware of the history issue as well. In that case, I’ll close it and we’ll wait for Daniel to recreate the branch.

sorted https://github.com/opencart/opencart/tree/4.x.x.x

Congratulations to everyone!
This is what you need.

To speed up the process, I can offer fixes that I have already collected. This will save a lot of time. I can prepare PR.
I'll now post a list of what I've already done.
If it’s suitable, I’ll prepare a PR

Note regarding sources

Entries accompanied by a reference link indicate code borrowed or adapted from external sources.
Entries without a reference link were developed exclusively within the oc-plus-plus repository.

Added

• #14857, #14858, #14859 - Add manufacturer filter
• Emulation of GLOB_BRACE for Alpine/musl environments:
  introduced a custom oc_glob() helper function to emulate native glob functionality.
• The date_added field has been added to the product form

Changed

• #14753 - Retrieve more in depth files from extension directory for permission.
• #14780 - Admin Filter Improvements.
• #14790 - Updated catalog/language/en-gb/default.php, added text_all.
• #14818 - Safest one just in case the product options are empty.
• #14820 - Event list: always allow for viewing event details.
• #14891 - To collect cache files, do it only if the random has fallen to the cleanup.
• #14915 - Add OPTIMIZE TABLE to db.php.
• 0a8b25a - Added some additional form text.
• 8996eb3 - partially used - Improved admin/controller/marketplace/installer.php.
• 062ba0e, 85e8ddb - partially used - Updated language methods.
• Refactored the codebase to replace all glob() calls using the GLOB_BRACE flag with oc_glob() emulator to ensure compatibility with Alpine Linux and other musl-based environments where GLOB_BRACE is unavailable.
• Improved Category and Product search for the Admin panel.
• Reduced the size of the "Delete" buttons on the 'Links' tab of the product form.
• Updated dependencies.

Removed

• d342547 - upload/system/helper/filter.php as unused.
• aws/aws-sdk-php package as unused.

Fixed

• #14438 - WYSIWYG misconfiguration in ADMIN page for product edit.
• #14498 - Sales order Store - wrong in the order list.
• #14731 - In additional Stores Cookie Policy is not selectable.
• #14736 - Fix disabled products design same as other table lists.
• #14739 - After creating multiple folders, the root directory images are not displayed.
• #14740 - Renamed total function as they had an incorrect name.
• #14744 - BUG in product settlement.
• #14746 - Various bugs with sku, upc, ean, jan, isbn, mpn.
• #14755 - Wrong total on cart page
• #14756 - Order files are not displaying in the admin order details page.
• #14758 - Unnecessary parameter
• #14759 - Checkout cart page lists wrong item totals.
• #14764 - Admin login as customer not working.
• #14770 - Incorrect glob path used in admin/controller/common/developer.php.
• #14791 - Fix wrong search result pagination.
• #14803 - Admin order notes are visible to the customer
• #14822 - In Admin, while creating new order, Product is not being added.
• #14843 - Fix autoloader in storeInstance to ensure proper class loading.
• #14845 - Missing language definition in account/forgotten.php.
• #14867 - Fix autoloader: one namespace can contain classes from different folders.
• #14878 - Wrong column used in topic layout methods (article_id instead of topic_id)
• #14882 - Undefined array key "payment_zones".
• #14886 - Fix Admin Filter Submit logout.
• #14887 - Argument 1 must be of type int, string given.
• #14895 - Should use array_merge.
• #14903 - Fixed getTotals().
• #15185 - Fix viewing embedded Youtube video.
• #forum - Error when deleting a product from Wishlist.
• Deprecation warning on PHP 8.4.
• The zone name was not displayed in the list
• The password recovery link in the email was visible as plain text
• Undefined array key "author" in catalog/controller/product/review.php on line 161
• getProduct(): Argument 1 must be of type int
• PHP Warning: Undefined array key "en-gb'nvOpzp;..." in catalog/controller/common/language.php

These improvements are available on several existing sites. It's been a couple of weeks since there's been a single error in the logs.

If you're happy with it. I will prepare a PR, each change in the form of a separate commit with a detailed description.

ok fixed the 4.x.x.x branch

I’ll do this now, it will take 1-2 days.

All tasks completed ahead of schedule.
I have finished porting and verifying.
The PR is now ready for final review and merge.
#15315

@batumibiz

In this scenario.

Old repository tag with technology used, if Opencart moving toward JS it does mean support for "classic" PHP should not for longer term and we must learn to adapt new ways to do things, so instead of moving Opencart JS to new Repository it's does make sense to move "classic" PHP 4.x.x.x to different repository named OPENCART-PHP which indicates particular repository is for PHP.

Opencart project should stay on root repository regardless of shift and choice of language JS or DOT NET or PYTHON, .ETC .

For clarity old things label as OLD with technology tag.

I respectfully disagree.

The "OLD" label should only be applied to versions that are no longer maintained. Currently, even the 3.x.x.x branch receives active support, and we are working hard to stabilize the 4.x.x.x branch. These are living, breathing versions of the software—they are far from "old."

Regarding the repository shift:

The PHP version has been evolving for many years. It has a massive community and a vast ecosystem of essential extensions. In short, it is a proven, stable environment that powers millions of businesses.

In contrast, the JS version is currently an experimental development. It is yet to be seen how successful it will be or how the developer community will embrace it. We all know that without a strong library of high-quality extensions, any new platform is destined for obscurity. For the PHP version, this ecosystem already exists; for the JS version, it remains a huge question mark.

Why break a functional, thriving ecosystem for the sake of an experiment? The root repository should belong to the version that the community and businesses actually rely on.

Let’s imagine for a moment that a separate repository is created for the PHP version, and all future PHP development moves there (honestly, I would even agree to this just to finally bring some order).

But then, what happens to the version numbering for both the PHP and JS variants? Which one earns the right to be called OpenCart 5.x.x.x?

If you argue that the JS variant should take the "5.x" title, I have to ask: why take that right away from the PHP version? Historically, OpenCart is built on PHP. It is only logical that the natural progression of version numbers stays with the original architecture.

A new, experimental development should start its OWN numbering from scratch. You don't just "hijack" the version history of a mature project for an experiment that has yet to prove its worth to the ecosystem.

Let’s imagine for a moment that a separate repository is created for the PHP version, and all future PHP development moves there (honestly, I would even agree to this just to finally bring some order).

But then, what happens to the version numbering for both the PHP and JS variants? Which one earns the right to be called OpenCart 5.x.x.x?

If you argue that the JS variant should take the "5.x" title, I have to ask: why take that right away from the PHP version? Historically, OpenCart is built on PHP. It is only logical that the natural progression of version numbers stays with the original architecture.

A new, experimental development should start its OWN numbering from scratch. You don't just "hijack" the version history of a mature project for an experiment that has yet to prove its worth to the ecosystem.

Yes, this looks more correct. A new version that will be developed in a new technology. Should start from scratch.
Keeping the main stable version as it is.

I think it can take time for people to shift from PHP to JS.
So they should have something stable while they decide to shift.

I agree @batumibiz , Opencart JS is a new project and needs a new repository.

Opencart PHP remains in /opencart as it always has, so as not to confuse new users.

One detail is that Opencart.com and similar sites should continue to focus on Opencart PHP, even if it means focusing on version 3 and discarding version 4, or improving version 4 as suggested by colleagues.

Now it would be good to consider whether an Opencart JS is really worthwhile. I don't know what it will be like, but if it's going to be 100% JS on both the front-end and back-end, I consider it a mistake. The JS dependencies are absurd; just look at node_modules and how easily it breaks and becomes enormous. JS is for the front-end and even then, it should be used in moderation. In new projects, I'm using Alpine.js on the front-end to simplify things even further. I even cut Vue.js and keep Twig as the template engine + Slim PHP as the framework.

In any case, I wish good luck with the new project and I'm also curious about how it will be regarding plugins/apps. One idea would be to follow the Hugo CMS model, perhaps keeping the pure PHP backend, which generates the static frontend with API calls for dynamic elements like My Account, Cart, Checkout, and so on, but maintaining a very clean JS. If it's going to be without a frontend, it would be good to at least have a base theme for example and examples of how visual plugins and others can be made.

I'll keep my focus on Opencart 3 and maybe the future 4, but I'm curious about this new project and that it learns from the mistakes of Opencart 4; it needs testing! A clear roadmap and changelogs are also necessary, as well as a strong focus on maturity and ease of use.

Opencart's success was due to its ecosystem and its ease of use and excellent performance, not to mention its maturity.

I am not just referring to the storefront themes.
I am talking about the back-office (admin panel).
While third-party themes like Journal or Maza handle the customer-facing side, the core admin UX remains outdated and creates a high barrier to entry for new users.

Furthermore, we are severely lacking in comprehensive, up-to-date documentation.
If we want to attract new developers and merchants, the official OpenCart website needs a modern overhaul and a robust 'knowledge base.'
Without clear guidance and a modern interface, we risk losing the next generation of users to more 'user-friendly' competitors. It’s time for the platform to look and feel as professional as the code powering it.

I am talking about the back-office (admin panel).
While third-party themes like Journal or Maza handle the customer-facing side, the core admin UX remains outdated and creates a high barrier to entry for new users.

I think the back office is actually quite intuitive with a modern UI as it is, and not too dissimilar to PrestaShop. Of course, OpenCart UX is simpler and lacks some features and automation needed for an efficient workflow—but that’s a separate issue. What do you have in mind for the back office? Can you share any examples?

One of the biggest improvements OC4 could make is moving away from the 10+ tabs required to add a single product. Switching to a unified long scroll page similar to Woo, it would be a game changer.

Interesting… I have completely different needs. I agree that some of the tabs could be combined into one, but I don’t see how that would be a game changer. As far as I understand, most people process orders daily rather than create new products every day. From my perspective, bulk product upload and bulk updates would be far more valuable features. Anyway, when I look at PrestaShop and other similar platforms I see that they all use tabs.

Regarding the Admin panel, I think it's very good and better than most systems, but of course, improving with each major version is part of the process.

As for the Front-end, I disagree with examples of themes like Journal. I consider one of the biggest problems with Opencart and other e-commerce platforms to be themes that are outside the platform's standard, with numerous bugs, heavy loads, and overly focused on features. I always advise against using Journal, Pavo, Lexus, Burn Engine, and similar themes. I don't even know if they should be considered themes, but rather new catalogs that try to do everything and do nothing well. Unfortunately, many people use these "themes."

A suggestion I've already made would be to highlight themes based on the Opencart structure and a strong focus on quality, not just unlimited features.

Now, the Opencart theme should mature. The time spent on Opencart 4 years would have been much better spent creating a modern theme from scratch. I don't mean filling it with JS, but a beautiful, clean, and more modern theme with updated CSS, JS, and other elements.

WooCommerce is far from being a good example, but it's a fact that many people use it, even though it's a WordPress plugin, and many use WP for everything even though it's not recommended and is less secure than Opencart, which focuses solely on being an e-commerce platform.

I think migrating from Opencart to WooCommerce is a mistake, but it's a matter of choice, perhaps because it has more users and therefore a theoretically larger ecosystem.

I agree about the versioning; it lacks a Roadmap, a clear Changelog, an LTS (Long Term Support), testing, and a clear plan and objective for the future, which also hampered the excessive focus on features that began in Opencart 4.

If they had created a new theme for Opencart 3, perhaps a new checkout with truly functional and good Alpine.js, modernized the admin interface a bit, improved file uploads, and a few other details, that would already be a far superior evolution to what Opencart 4 has been.

As for the outdated default theme, I recommend reaching out to well-known designers who specialize in OpenCart. Some of them would likely agree to provide one or two of their themes to be included in the official OpenCart distribution for free. In exchange, the author would receive an official credit and a backlink.

This is standard practice for open-source projects, and I believe many designers would support this initiative.

we can remove osme of the pages and replace them with modals.

we can remove osme of the pages and replace them with modals.

Doing this right now is counterproductive. The default theme should remain as simple and lightweight as possible. Any serious merchant will eventually replace it with a professional theme designed for their specific needs.

Our priority should be providing a stable and reliable foundation.

Moreover, we must avoid touching core system logic to ensure backward compatibility. Extension developers are already struggling to keep up with the constant changes...

Agree on everything.

Doing this right now is counterproductive. The default theme should remain as simple and lightweight as possible. Any serious merchant will eventually replace it with a professional theme designed for their specific needs.

Let me add my experience here: using custom themes—even high-end ones—can create additional lock-in issues by overriding and replacing core elements instead of extending them. They also tend to introduce their own menus hierarchy in the back office. In other words, they are beautiful if standalone.

Once the more pressing issues are resolved in OC, in my opinion the default template should evolve to be good enough for anyone who wants to open a hobby store.

The problem with commercial themes is that most are terrible, but unfortunately many people replace the native theme with paid themes that are non-standard for the platform and slow, haha.

I agree, the main theme has to be a solid and more generic base, even to be customized for whoever will use it or serve as a base for commercial themes.

It's super complex and annoying to deal with non-standard themes or versions with drastic changes, because you have to adapt the plugin again or spend 30-60 minutes or more installing it, and that's when the theme isn't a Journal or Burn Engine with terrible standards and its own logic. What would take 1-5 minutes in a well-made theme can take hours in these non-standard themes.

Opencart becoming more stable is better for everyone. Opencart 4 itself had a drastic change in how we create plugins and even the folder structure, which means we already have to maintain versions for Opencart 3 and 4, not to mention the removal of OCMOD, which was the biggest mistake of all and then returned incomplete.

@danielkerr @mhcwebdesign
Let’s wait a bit. There are still a few pull requests under review for 4.x, and some cleanup left to do. No need to rush the release.

I can release the next 4.x version once you guys ae ready.

are we ready for the next release.

are we ready for the next release.

@danielkerr : The 4.x.x.x branch is almost there. The only major outstanding issue is the admin order edit, see #15472

@batumibiz : There are still a few outstanding issues we are trying to resolve in the 4.x.x.x branch. Also, have you done any recent bugfixes in your repository which aren't yet in the 4.x.x.x branch?

Yes, I have already added the latest bugfixes from your branch.
For my part, I also finished everything that was in my immediate plans.

I'm waiting for a decision on the branch, I'm ready to send it as a PR, but I need a clean branch from 4.1.0.3
#15300 (comment)

@batumibiz : What else have you changed that isn't yet in the 4.x.x.x branch? If there important fixes (not additional features) please create separate pull requests!

We've already discussed this, don't make me repeat the same thing.
#15366

Guys,

Any news of when a 4.x can be released.

We are pretty much there. All I need to do do is to add some updates to ensure the upgrade script from 4.1.0.3 to 4.1.0.4 works without hickups. I'll let you know when it's done, hopefully sometime this week.

Sorry for the long delay, but as you can see form the CHANGELOG.md at https://github.com/opencart/opencart/blob/4.x.x.x/CHANGELOG.md we had a lot of valuable contributions for bugfixes, along with some thorough testing.