Requirements¶
Check these before you buy, and again before you install on a store you care about.
OpenCart¶
OpenCart 4.0.2.0 through 4.1.0.3, which is 4.0.2.0, 4.0.2.1, 4.0.2.2, 4.0.2.3, 4.1.0.0, 4.1.0.1, 4.1.0.2 and 4.1.0.3. Where a release is tested it is tested the same way: a release archive installed on a store built for the occasion and then put through import, apply, rollback, export, a scheduled run, an upgrade over itself and an uninstall. The older releases get that same pass, not a reduced version of it.
Four of those eight releases have a fault in OpenCart itself, and each costs some extensions a feature. Which release, and which extension loses what, is below and on each extension's own Limits page. An extension that loses something on a release does not claim it: the list on its own Installing page is the record of the releases a full pass was actually run on, and it is the only list its marketplace listing claims from.
4.1.0.4 is supported too, extension by extension as each one is run against it. Each extension's own pages say which releases it has been through. What is broken on that release belongs to OpenCart rather than to any extension, and is below.
They will not work on OpenCart 3.x or earlier. Version 4 changed how extensions are packaged and how the store finds their files, so a 3.x store cannot install these archives at all. An archive that will not install is the better outcome, because it fails immediately rather than half-working.
They will not install on 4.0.1.1 or anything older, and they will tell you
so rather than let you find out. Those releases have no cron.php, the file the
store's own scheduler runs under, so anything that was meant to happen on a
schedule could not happen at all. Rather than install and then do nothing,
the extension declines, creates none of its tables, and says on its own screen
which version you have and which you need. Upgrade OpenCart to 4.0.2.0 or later
first.
On a release newer than 4.1.0.3 they install and run, and say that they are untested. A version we have not run a pass against is not the same thing as a version we know to be broken, and refusing to start on the morning you upgrade OpenCart would be the worse of the two mistakes. You get a note on the screen saying which release is the newest we have tested; if something misbehaves, please tell us rather than assume it is your data.
If you are unsure which version you run, it is printed at the bottom of every page of your admin.
One exception: Product Bundles needs 4.1.0.1¶
Product Bundles starts at 4.1.0.1, not 4.0.2.0. Everything a bundle tells your cart (what the line costs, whether it can be made, what it weighs, what it earns) travels on one piece of OpenCart that only exists from 4.1 onwards. On a 4.0.2.x store it could not tell the cart any of that, and the worst of the consequences was that a customer could reach checkout holding a bundle you had no way to pack. So it declines to install there and says which version you need, the same way every extension declines below 4.0.1.1.
4.1.0.0 is below that floor as well, and for the same reason rather than a different one. That release has the piece of OpenCart a bundle needs, and the column it stores in is declared one byte wide, so OpenCart writes what the bundle says and the store keeps none of it. A bundle would be charged at its carrier product's own price, its availability would be OpenCart's answer rather than its components', and the checkout block would never apply, with nothing on any screen saying so. Being charged the wrong amount for an order that has already been paid is not a limitation to describe; it is a release to decline. 4.1.0.1 widened the column, and that is where the floor is. Every other extension on this site still installs on all eight releases above.
The releases where OpenCart itself has a fault¶
Four releases in the supported range carry a fault in OpenCart's own code. None of them is an extension's fault, none of them is an extension's to repair, and in every case upgrading OpenCart is the whole of the remedy. An extension affected by one of them says so on its own screen, naming your release and what you have lost; an extension untouched by one says nothing, because nothing has changed for it.
| Release | What OpenCart itself gets wrong | Fixed in | Who loses something |
|---|---|---|---|
| 4.0.2.3 | The review form loads a file that release does not have, so no shopper can submit a review at all. Reading reviews is unaffected. | 4.1.0.0 | Review Requests |
| 4.1.0.0 | Copying a product re-uses the option identifiers of the product being copied, so Copy fails with a duplicate-entry error. Sorting any listing by price is built as invalid SQL and answers a database error. | 4.1.0.1 | Product Configurator, Product Search |
| 4.1.0.1 | Guest checkout answers a PHP warning ahead of its reply, which the browser cannot read, so Continue does nothing. Adding a language is refused for a language nobody has added. | 4.1.0.2 (guest checkout), 4.1.0.3 (languages) | Delivery Date, Pre-Order, Review Requests, SEO Suite Pro |
| 4.1.0.2 | Adding a language is refused for a language nobody has added. | 4.1.0.3 | SEO Suite Pro |
| 4.1.0.4 | The store's own scheduler cannot run at all; see below. | not yet | Pre-Order, Review Requests, SEO Suite Pro, Import/export, Back in Stock, Product Feed, Wishlist, Advanced Product Filters |
If you are choosing a release to be on, 4.1.0.3 is the one with none of this on it.
4.1.0.4: supported, with the store's own scheduler broken¶
4.1.0.4 is a version to install these extensions on. Every screen, every form and every storefront page behaves exactly as the rest of this site describes. What is broken there is OpenCart's own scheduler, and only that.
On a stock 4.1.0.4 store, cron.php (the file the store's scheduler runs
under) starts without the composer autoloader, and stops with
Class "Twig\Loader\FilesystemLoader" not found
inside OpenCart's own code, before any extension is reached. That release moved
the autoloader into system/framework.php and commented out the line in
cron.php that used to load the older one. cron.php is the one entry point
that never loads framework.php (index.php, admin/index.php and
install/index.php all do), which is why the rest of the store is fine and
scheduled work is not.
Nothing an extension can do from inside that path fixes it: the crash happens before an extension's code runs at all. It is OpenCart's to repair.
What that costs you depends on the extension, and each one says so on its own
page. Most of them have nothing on a schedule, so they lose nothing here.
The ones that do give their scheduled work a second door that does not go
through cron.php, and their own Installing page is where that door is
written down: which command to run, or which address to give your host's cron
service. Start there rather than here: a list in this shared page would be one
more thing to go stale the first time a single extension changed.
If your store is on 4.1.0.4 and something that was meant to run on a schedule has not run, that is the first thing to check.
PHP¶
PHP 8.1 through 8.4, which is 8.1, 8.2, 8.3 and 8.4.
PHP 8.0 and anything older is below the minimum. The code is written to 8.1, so an older interpreter stops at a parse error before a line of it runs, and your store answers with a blank page and nothing in any log. 8.1 is a floor rather than a recommendation: it is itself past security end-of-life, so if your host offers you something newer, take it.
8.4 is on that list because OpenCart is clean on it. We read all 4,327 PHP files of a 4.1.0.3 release looking for anything 8.4 deprecated, and found none: the libraries OpenCart bundles are current, and the older way of writing a nullable argument (the thing 8.4 began warning about) has already been converted throughout.
On a PHP newer than 8.4 the extensions install and run, and this page is where they say they are untested. A version we have not run a pass against is not the same thing as a version we know to be broken, and refusing to start on the morning your host moves you to a newer interpreter would be the worse of the two mistakes. There is no note on your screen for this one (that note exists for your OpenCart version, not for your PHP version), so if something misbehaves after a PHP upgrade, please tell us rather than assume it is your data. PHP 8.5 is the exception, and what is wrong there is below.
On PHP 8.0 or older the extension declines to install rather than half installing. Nothing is created, and a line in your store's error log names the version you are on and the version you need. That is deliberate: below 8.1 the extension cannot run at all, and an install that went ahead would leave you with a blank admin page and nothing to go on. There is no equivalent refusal at the top end: on a PHP newer than the versions above, the extension installs and works, and we have not run the pass on that version yet.
Your admin will not tell you it declined. OpenCart reports Success for
every module install whatever the module does, and lists the extension as
installed, so a refusal here looks exactly like an install that worked. The
error log is the only place it is written down, and nothing prompts you to look
there. If an extension installed without complaint and then left no screen and
no settings behind, open System → Maintenance → Error Logs and search for
install refused. Once your host has moved you to 8.1 or newer, uninstall
the extension and install it again: OpenCart already counts it as installed,
so there is no Install button to press until you do.
Your hosting control panel will tell you which version your store uses. If you cannot find it, your host can.
Why 8.5 is not on the list¶
This is a fault in OpenCart, not a version we have not got round to. The two are worth telling apart, because the two take very different lengths of time to go away.
PHP 8.5 deprecated curl_close(), and OpenCart still calls it: from
system/library/curl.php, the HTTP client the rest of the store shares, and
from sixteen other places besides. On its own that would be a line in a log.
But OpenCart's own error handler writes a deprecation notice into the page it is
building, so with error display switched on the notice comes out in the middle
of what your customer is reading. The call that fires on the storefront is the
currency refresh, and that is only due on some requests, so a store looks right
all morning and then serves one broken page at lunchtime, which is the hardest
kind of fault to be told about.
Nothing an extension can do from inside that path prevents it: the notice comes out of OpenCart's code before ours is reached. It is OpenCart's to repair, and when it is repaired 8.5 joins the list above.
Database¶
MySQL 5.7 or later, or MariaDB 10.4 or later, which is the same requirement OpenCart itself has, so a store that runs is already a store that qualifies.
Access you will need¶
- An administrator account that can reach Extensions → Installer. On most stores this means the top-level administrator group.
- Enough disk space for the upload. The archives are small (well under a megabyte), but a store that has run out of space fails the upload in a way that looks like a broken download.
What is not required¶
- No shell or SSH access.
- No composer, no build step, no file editing.
- No changes to your server configuration.
Everything is done through the admin, from the archive you downloaded.
Next: installing an extension.