The Future of OpenCart: Version 5.x, opencart.js and the PHP Branch

OpenCart is entering a period in which one platform is effectively turning into two projects. In September 2026, founder Daniel Kerr published a 5.x.x.x roadmap on GitHub describing the future OpenCart as a system of pre-generated static HTML, CSS and JS files hosted on Cloudflare, AWS or GitHub. He also proposed launching a separate repository under the working name opencart.js and handing the master branch over to the community. For thousands of stores running on OpenCart and for extension developers, these decisions will shape technical strategy for years to come. The OpenCartBot team has worked with the platform since 2015 as an official partner, so we assessed the new concept from the standpoint of running real online stores.

How OpenCart Reached This Turning Point

The current situation is the result of several years of unstable development. Release 4.0.0.0 brought PHP 8.1, Bootstrap 5, a new event-based extension system and product variants. The same release removed OCMOD and all third-party extensions from the core. For extension developers, this meant rewriting code for the new architecture. OCMOD later returned in version 4.1.0.0, and part of that work had to be revisited a second time.

Project collaborator stalker780 described this period in plain terms: for at least six years, store owners had to choose between the outdated third version with Bootstrap 3 from 2013 and an unstable fourth version that broke compatibility with almost every minor update. Some merchants moved to WooCommerce, Shopify and marketplaces during that time.

Stabilization came from the community. On August 11, 2026, versions 3.0.5.1 and 4.1.0.4 were released simultaneously with official PHP 8.5 support. The previous stable release of the 4.1 branch appeared on March 24, 2025, almost seventeen months earlier. The OpenCartBot team contributed ten of its own fixes to 4.1.0.4. Over recent years, most of the maintenance work on both branches has been done by collaborator mhcwebdesign together with other community members.

The OpenCart 5 Concept

Kerr attributes the change of direction to shifts in the market. In his view, business owners no longer want to maintain their own script that requires constant security checks and updates. This leads to the idea of a store made of ready-built files with almost no server side. The 5.x.x.x roadmap includes the following changes:

• the storefront runs on HTML, CSS, JS, JSON, YAML and CSV files;
• product descriptions are written in Markdown;
• PHP handles only static page generation, form submissions and email delivery;
• the admin panel also consists of static pages;
• extensions are activated in fewer steps;
• built-in connectors upload the finished store to hosting, Cloudflare or AWS.

Kerr also stated that a single cPanel account will be able to manage millions of such stores. No technical specification, prototype or timeline has been published for this claim so far.

Strengths of a Static Architecture

The pre-generated page model has been proven over years by generators such as Hugo, Eleventy and Astro. For an online store, it offers several measurable advantages. Static pages are served from a CDN in tens of milliseconds, which improves Core Web Vitals and Google rankings. Hosting costs are minimal: Cloudflare Pages and GitHub Pages serve static sites free of charge within their limits. The attack surface shrinks sharply because the storefront has no database or PHP code, which are the most common entry points for store compromises.

The security argument has real grounds. Mass attacks on plugin-based CMS platforms happen regularly, and small store owners rarely install patches in time. A static storefront removes a significant share of that risk.

Limitations of the Static Approach for E-commerce

A store consists of processes that change constantly. Customer group pricing, time-limited specials, stock levels, coupons, taxes, multi-currency support, the cart and checkout all require current data at the moment the customer acts. The published roadmap does not describe where orders, customer accounts and stock levels will be stored.

Page regeneration creates a separate load. A catalog of 10,000 products in three languages contains 30,000 product pages, plus categories, manufacturer pages and filters. Changing the price of one product requires rebuilding its page, every listing that includes it and the search index. A store that syncs stock with its accounting system several times an hour would effectively remain in a continuous generation cycle.

For the Ukrainian market, the list of server-side tasks is even longer. Selecting a Nova Poshta branch and calculating shipping work through a real-time API. LiqPay, monobank and WayForPay send callback requests whose signatures are verified on the server. Fiscalization through software cash registers such as Checkbox, product exports to Prom and Rozetka, and data exchange with BAS or 1C also require server code. All of this logic will need updates and protection, so the security problem moves to another part of the system.

A developer from Brazil raised another point in the roadmap discussion. OpenCart originally spread thanks to easy installation on any low-cost hosting, and moving to Cloudflare or AWS may prove difficult for small businesses. Configuring builds, deployment and serverless functions takes skills that most small store owners do not have.

PHP Remains the Foundation of Mainstream E-commerce

Kerr justifies the new direction by saying that web development is moving away from PHP. The statistics confirm this only for a specific segment. According to W3Techs data for August 2026, PHP is used by 70.3% of websites with a known server-side language, and server-side JavaScript accounts for 7.2%. Among the top 1,000 websites, the split is 59.2% for PHP and 29.2% for JavaScript.

The shift toward JavaScript is happening among high-traffic projects with in-house development teams. OpenCart's audience belongs to the small and medium business segment, where PHP dominates and will remain the standard for years to come. The PHP version of OpenCart therefore keeps its market niche regardless of what happens with opencart.js.

Two Directions for OpenCart

After the GitHub discussion, the outline of the new project structure became clear. Collaborators proposed splitting the repository into branches by version number:

• 3.0.x.x receives bug fixes and support for new PHP versions;
• 4.1.x.x receives bug fixes and support for new PHP versions;
• 4.2.x.x becomes the development branch for the next PHP version and opens by default in the repository.

mhcwebdesign supported this scheme and confirmed that the master branch has already moved substantially away from PHP toward static pages and JS/JSON, so it makes sense to spin it off as a separate opencart.js project. Participants proposed introducing a new database structure in 4.2 and improving the core, the event system and OCMod. Kerr agreed to hand the master branch to the community and work on the new project in a separate branch.

As a result, OpenCart 4.2 will develop as an evolutionary continuation of version 4 with compatibility preserved. Opencart.js becomes an experimental product with a different architecture, which Kerr plans to offer users once it is complete. Organizational questions remain open. Participants asked for maintainer rights for active collaborators, a GitHub Projects board for planning and a chat for coordination. The pace of upcoming releases depends on the answers to these requests.

The Extension Ecosystem in the New Setup

For the extension market, the two directions mean different scenarios. Extensions for the 4.1 branch will work in 4.2 without significant changes, provided the community keeps its course toward backward compatibility, which collaborators describe as a priority. The new database structure in 4.2 may require adapting extensions that work directly with product and order tables.

Opencart.js will have no compatibility with existing extensions. Controllers, models, Twig templates, events and OCMOD modifications have no counterparts in a static architecture. Every payment, shipping or data exchange extension will have to be redesigned from scratch once an extension API specification appears. The transition from version 3 to version 4 shows that rebuilding an ecosystem after such a change takes years.

Strategy for Stores in the Coming Years

Stores on version 3 should update to 3.0.5.1. This build runs on PHP 8.5, so the eventual removal of older PHP versions from hosting will not cause urgent problems. New projects are best launched on 4.1.0.4, since this branch will become the basis for 4.2 and will keep receiving community fixes.

There is no reason to postpone updates while waiting for OpenCart 5. The static version exists as a plan of a few paragraphs, with no architecture document, dates or migration path. A store on 4.1 can already get the speed that static pages promise through full-page caching, Redis and catalog caching at the Cloudflare level.

Extension developers should build on the event system and OCMOD in the 4.1 branch and track database structure changes in 4.2. Business owners planning to run on OpenCart for several years ahead benefit from following the repository and taking part in release candidate testing. The PHP version is now developed by the community, and every bug report or pull request directly affects when 4.2 ships.