Keeping an old OpenCart 2 or 3 shop running safely

You can keep an old OpenCart shop trading, and plenty of people do. The trick is to stop treating it as software that needs updating and start treating it as a machine that works: freeze the shop itself, modernise everything around it, and cut down how much of it is reachable from the internet.

That is the whole approach in one sentence. The rest of this is the order we do it in when a 2.x or 3.x shop lands with us, and the jobs a shop owner can get done in an afternoon without a developer.

Find out exactly what you have

People tell us “it’s OpenCart 3” and it turns out to be 3.0.2.0, which behaves differently from 3.0.3.8 in ways that matter. Open index.php in the shop’s root folder and look near the top for the line beginning define('VERSION'. The four numbers after it are the truth. The admin footer usually shows the same thing, though a themed admin sometimes hides it.

Write that number down somewhere you will find it again, along with the PHP version the site is actually running on and the name of whoever built the shop. When something goes wrong at half past four on a Friday, having those three facts to hand saves an hour of poking about. If you want to know what your particular version expects from a server, we have set the requirements out release by release.

List every modification before you touch anything

Here is the thing that makes old OpenCart shops different from old WordPress sites. The files sitting on the server are frequently not the code that runs.

Two systems do this, and most older shops have both.

• vQmod is the third-party one that came first. XML files in the vqmod folder describe edits to core files, and vQmod builds patched copies into its own cache directory as pages are requested. Look in vqmod/xml and count what is in there.
• OCmod is OpenCart’s own version, built into 2.0 onwards. You will find it under Extensions, then Modifications, with a refresh button that rebuilds the patched copies into the modification folder inside your storage directory.

Both work by searching for a snippet of code and replacing it. Which is fine until two modifications want the same line. The first one changes it, the second one goes looking for text that is no longer there, fails, gets a line in the error log that nobody reads, and is quietly skipped. Your shop then runs the unmodified core behaviour for that feature. This is why a shop can start behaving oddly after an extension is installed, with no error on screen at all.

So before anything else, take a copy of the vqmod/xml folder, screenshot the Modifications list, and note anything your developer edited directly in core files. That third category is the dangerous one, because nothing in the admin will ever tell you it exists.

The hardening jobs worth doing this month

None of these change how the shop works for customers. All of them reduce what an automated scanner can reach.

• Delete the install folder if it is still sitting there. On shops that have been moved between hosts a few times it usually is.
• Rename the admin folder and update the paths in admin/config.php to match. It stops the constant login attempts against the obvious URL.
• Put the admin behind an IP restriction or a second password at the web server level. Almost no shop needs its admin reachable from every country on earth.
• Move the storage directory outside the web root and point DIR_STORAGE at the new location in both config files. Sessions, logs, uploads and digital downloads then stop being things a browser can request directly.
• Remove extensions you no longer use rather than switching them off. A disabled extension’s files are still on disk and still reachable.
• Give every person their own admin login and delete the accounts belonging to people who left. Shared logins make it impossible to work out who changed what.
• Turn off error display to the screen, leave error logging switched on, and read the log occasionally. An old shop’s error log is the closest thing it has to a warning light.

Backups that will actually restore

OpenCart has a backup tool in the admin. On a shop of any size it is not the one to rely on, because it runs through the browser and a large order or product table will hit a time limit partway through. You get a file. It looks like a backup. It stops halfway down a table and you find out when you need it.

What you want instead is a database dump taken on the server, files taken separately, both copied somewhere that is not the same machine, and enough history to go back further than yesterday. If a shop is compromised, the damage is often weeks old by the time anyone notices, and a rolling three-day backup just gives you three compromised copies.

Then restore one. Onto a test address, once, so you know the file works and you know how long it takes. Until somebody has done that, what you are holding is a file that looks like a backup.

Get card details away from the old code

If your checkout asks customers to type their card number into a page served by your shop, that is the first thing to change, ahead of everything else on this list. It puts your old code in the path of card data, which is the one place old code should never be.

Nearly every gateway offers a hosted payment page or a hosted field arrangement where the customer’s card details go straight to the gateway and your shop only ever sees a result. Swapping an old direct-integration payment extension for the hosted equivalent is a contained job on a shop that otherwise stays exactly as it is, and it takes the scariest part of the risk off your server entirely.

Going from 2 to 3 is a migration, not an update

Worth knowing before somebody quotes you two days for it. OpenCart 3 changed the template engine underneath the shop, and what that means on your side of it is not a technical detail: every template in your theme, and every template shipped by every extension you have paid for, has to be rewritten or replaced. Your paid extensions need 3.x versions, which some vendors never produced. The step up to 4 is bigger again.

That is not an argument against upgrading. It is an argument against upgrading on a Sunday because a warning message annoyed you. Build it as a copy, run both side by side, put test orders through the new one, and switch when it behaves. Meanwhile the old shop keeps trading, which is the point of legacy PHP hosting in the first place.

The routine that keeps it boring

Once the shop is hardened and properly backed up, looking after it is a short monthly habit: skim the error log, check the last backup restored cleanly, look at the admin user list, confirm the cron jobs still ran, and put a couple of test orders through the checkout yourself. Ten minutes.

Everything else is the server’s problem, and on our OpenCart hosting it is ours rather than yours. Shops that have outgrown the old version and want a current one get the same treatment from the other end.

Old OpenCart FAQs

Send us the shop and we will tell you where it stands

Give us the URL and the version number and what comes back is a written assessment: which modifications are actually live, what is reachable from the internet that should not be, and which of the jobs above are already done. No upgrade quote attached to it and nothing to sign. Phone 01623 650 333 and the person picking up has been inside an OpenCart admin before, which is more than you get most places. Hosting starts at £1 a day + VAT if you decide to bring the shop here afterwards.