Keeping an old OpenCart 2 or 3 shop running safely

Find out exactly what you have

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, modernise everything around it, and cut down how much of it is reachable from the internet. What follows is the order we do it in when a 2.x or 3.x shop lands with us, plus jobs an owner can get done in an afternoon.

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, though a themed admin sometimes hides it.

Write that down with the PHP version the site actually runs on and the name of whoever built the shop. At half past four on a Friday, those three facts save an hour. What each version expects from a server is in our guide to OpenCart hosting requirements.

List every modification before you touch anything

This is what makes old OpenCart shops different from old WordPress sites: the files 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 as pages are requested. Look in vqmod/xml and count what is there.
• OCmod is OpenCart's own version, built into 2.0 onwards. It lives under Extensions, then Modifications, with a refresh button that rebuilds the patched copies into the modification folder in 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 changes it, the second looks for text that is no longer there, fails, writes a line to an error log nobody reads, and is skipped. The shop then runs unmodified core behaviour for that feature, which is why a shop can start acting oddly after an extension is installed with no error on screen.

So first, copy 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 the shop for customers. All of them reduce what an automated scanner can reach.

• Delete the install folder if it is still there. On shops moved between hosts a few times, it usually is.
• Rename the admin folder and update the paths in admin/config.php, which stops the constant login attempts against the obvious address.
• Put the admin behind an IP restriction or a second password at 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 it in both config files, so sessions, logs, uploads and downloads cannot be requested by a browser.
• Remove extensions you no longer use rather than disabling them. A disabled extension's files are still on disk and still reachable.
• Give every person their own admin login and delete accounts belonging to people who left.
• Turn off error display on screen, keep error logging on, and read the log now and then. It is the closest thing an old shop has to a warning light.

Backups that will actually restore

OpenCart's admin backup tool runs through the browser, and on a shop of any size a large order or product table hits a time limit partway through. You get a file that looks like a backup and stops halfway down a table, and you find out when you need it.

What you want is a database dump taken on the server, files taken separately, both copied to a different machine, with enough history to go back further than yesterday. A compromise 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 how long it takes. Our hosting keeps daily backups for 14 days.

Payments, and why 2 to 3 is a migration

If your checkout asks customers to type their card number into a page served by your shop, change that before anything else on this list. It puts old code in the path of card data. Nearly every gateway offers a hosted payment page or hosted fields, where card details go straight to the gateway and your shop only sees the result. Swapping an old direct-integration extension for the hosted equivalent is a contained job, and the rest of the shop stays exactly as it is.

Know this before somebody quotes two days for an upgrade. OpenCart 3 changed the template engine to Twig, so every template in your theme, and every template shipped by every paid extension, has to be rewritten or replaced. Your extensions need 3.x versions, which some vendors never made. The step to 4 is bigger again. That is not an argument against upgrading, only against doing it on a Sunday because a warning annoyed you. Build it as a copy, put test orders through it, and switch when it behaves. Meanwhile the old shop keeps trading on our legacy PHP hosting.

The routine that keeps it boring

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

Everything else is the server's job, and on our OpenCart hosting it is ours rather than yours. Send us the shop's address and version number and we will tell you which modifications are live, what is reachable that should not be, and which of these jobs are already done, with no upgrade quote attached. Ring 01623 650333 and you will speak to someone who has been inside an OpenCart admin before. dijihost Complete Hosting starts at £1 a day + VAT, migration included.

Related