Key facts
- OpenCart 2.x suits PHP 5.6 and early PHP 7; late 3.0.3 releases suit PHP 7.4; OpenCart 4 needs PHP 8.
- Your PHP ceiling is set by the oldest extension in the shop, not by OpenCart core.
- Required PHP extensions include cURL, ZIP, Zlib, GD, mbstring and OpenSSL; older shops also need mcrypt, removed in PHP 7.2.
- Strict SQL modes such as ONLY_FULL_GROUP_BY can break older OpenCart queries.
- PHP's default max_input_vars of 1000 silently drops form fields on large product edits.
- OpenCart has no full page cache built in, so category pages are built fresh for every visitor.
- dijihost Complete Hosting is £1 a day + VAT, with PHP 5.6 to 8.5 selectable per site.
Why the documented minimum is not enough
OpenCart's documented system requirements would fit on a postcard, and almost any hosting plan sold today meets them. That is exactly why so many shops end up somewhere that fights them. Meeting the minimum gets the software installed. It does not get you a shop that stays quick on a Friday afternoon.
Four things decide whether a server suits an OpenCart shop: the PHP version matched to your OpenCart version, a database whose defaults are not at war with the shop's queries, a handful of PHP limits that go unmentioned until they bite, and enough headroom for the pages OpenCart builds from scratch every time.
The PHP version has to suit your OpenCart version
| OpenCart | Comfortable PHP | Watch out for |
|---|---|---|
| 2.x | PHP 5.6 and early PHP 7 | Warnings first and broken extensions second on PHP 7.4 |
| 3.x (Twig templates, from 2017) | PHP 7.4 on the later 3.0.3 releases | On PHP 8, core copes better than expected but older extensions often do not |
| 4.x | PHP 8 | A genuine restructure: 3.x extensions will not run |
The rule we go by: your ceiling is set by the oldest extension in the shop, not by core. A host that changes PHP versions on its own schedule is a real risk to a shop with a dozen paid extensions, however tidy the core install looks. If one has already emailed you, read what that PHP email actually means.
Check the extension list too: cURL, ZIP, Zlib, GD, mbstring and OpenSSL, plus mcrypt on older shops. That last one catches people out, because mcrypt was removed from PHP in 7.2. If an old shop dies the moment it moves onto newer PHP, mcrypt is one of the first things to look at.
The database version matters less than its settings
MySQL or MariaDB, either is fine. What makes the phone ring is defaults. Newer versions ship with strict SQL modes on. ONLY_FULL_GROUP_BY rejects a shape of query older OpenCart code and extensions use freely, and the zero-date rules reject the placeholder dates old shops are full of. Neither announces itself politely: you get a blank category page or an order that will not save, and it looks like the shop is broken rather than the server being fussy.
MySQL 8 also changed its default authentication method, which older PHP builds cannot speak, so a shop that connected happily for a decade suddenly cannot reach its own database. Character sets matter as well: many older shops were created as utf8 rather than utf8mb4, so emoji in a delivery note and some accented names arrive mangled or refuse to save. Converting is a planned job, not a Sunday one. And shared plans cap database connections, while a shop with staff running reports during checkout uses several at once.
The PHP limits that quietly lose your data
Memory first. PHP's stock 128M is enough to browse a shop and not much else. Bulk edits, image resizing, exports and admin backups all want more, so 256M is a sensible floor for a working shop.
Then max_input_vars, the one we explain most often. PHP accepts a set number of fields in a submitted form, 1000 by default. A product with a long list of options or a busy category screen can post more. PHP does not error: it keeps the first thousand and throws the rest away, so you save the product and half the options vanish. If your shop keeps "forgetting" things you know you entered, start there.
After that, max_execution_time, because imports and admin backups are long jobs, and upload_max_filesize raised together with post_max_size, because extension packages and product photos both arrive as uploads and both fail confusingly when only one is generous.
Pages built from scratch, and files that pile up
This catches out hosts who mainly deal with blogs. A cached WordPress page costs the server almost nothing. OpenCart has no full page cache in the box, so a category listing means PHP running and the database answering, every time, for every visitor. Filters multiply it: every combination of manufacturer, price band and attribute is a separate URL, and a crawler will happily walk thousands of them overnight. In practice that means opcache on, PHP-FPM, and CPU you actually have rather than share with hundreds of neighbours. If a caching layer goes in front, cart and checkout stay out of it, and somebody tests that properly before it goes live.
Disk space is rarely the limit you hit. OpenCart keeps a resized copy of every image at every size the theme asks for, so a few thousand products become a very large number of small files, and shared plans cap file counts long before gigabytes. A noisy extension can grow the error log past the size of the shop, and the session and statistics tables keep every row they were ever given, because nothing in OpenCart prunes them.
What goes wrong on cheap shared hosting
Rarely one dramatic failure. Usually a series of small ones. The PHP version is chosen for you and changed on the host's timetable. Process limits throttle the shop just as a campaign lands, so the person who clicked your advert gets an error page. Cron is restricted or missing, so currency updates, feeds and scheduled exports stop without telling anyone. Order confirmations leave from a shared IP address whose reputation you had no part in, and some land in junk folders; our sister site covers why emails go to spam.
The costliest is support. If nobody on the desk has seen an OCmod conflict, every problem comes back as "please contact your developer", and you pay someone to diagnose a server you cannot see into. Running OpenCart 2 or 3? Read keeping an old OpenCart shop running; those shops live on our legacy PHP hosting. Current shops belong on our OpenCart hosting. Tell us what is installed and how big the catalogue is, on 01623 650333 or in writing, and we will size it. Hosting starts at £1 a day + VAT; a shop with two thousand products and fifteen extensions is quoted rather than guessed.
Frequently asked questions
What PHP version should I run OpenCart on?
Match it to your OpenCart version and your extensions. OpenCart 2 belongs on PHP 5.6 or an early PHP 7. OpenCart 3 is settled on PHP 7.4, with PHP 8 depending on how modern your extensions are. OpenCart 4 needs PHP 8. Your real ceiling is set by the oldest extension in the shop, not by core.
How much memory does an OpenCart shop need?
PHP's default of 128M lets people browse and buy, but it struggles once you use the admin properly. Bulk edits, product imports, image resizing and backups all want more. We treat 256M as the floor for a working shop and go higher for large catalogues rather than waiting for the first failed import.
Why does my shop lose product options when I save?
Almost always PHP's max_input_vars limit, which defaults to 1000 fields per form. A product with many options, or a busy category screen, posts more fields than that. PHP silently keeps the first thousand and discards the rest, so the page saves and part of your data disappears. Raising the limit fixes it.
Why does my host say my OpenCart shop has too many files?
OpenCart keeps a resized copy of every product image at every size your theme asks for, in its image cache folder. A few thousand products can turn into tens of thousands of small files. Shared plans often cap the number of files before they cap the gigabytes, so a shop can sit inside its storage allowance and still be over the limit.
Does OpenCart work with MySQL 8 and MariaDB?
Yes, but the settings matter more than the version. Strict SQL modes such as ONLY_FULL_GROUP_BY and the zero-date rules can break queries in older OpenCart code and extensions. MySQL 8 also changed its default authentication method, which older PHP builds cannot use. A host that knows OpenCart sets these to suit the shop.
Related
Set it up and forget about it
Managed hosting, Plesk, Cloudflare DNS, daily backups and your domain for £1 a day + VAT. We move your site for you.