Core files edited
Changes made directly to controller and model files instead of through OCMOD or events, silently lost or conflicting on every update.
[ E-commerce ]
OpenCart stores that are fixed properly, not patched again.
OpenCart is lean and cheap to run, which is why a lot of stores have been on it for ten years. The problems usually come from that history: a stack of marketplace extensions, core files edited by hand, and a version that no longer runs cleanly on a current PHP release.
Free store review · Fixed-price upgrades · Staging copy first
[ What goes wrong with OpenCart ]
Almost every OpenCart issue I am asked to fix traces back to how extensions were installed and how the core was modified.
Changes made directly to controller and model files instead of through OCMOD or events, silently lost or conflicting on every update.
Two OCMOD or vQmod files searching for the same line, so one fails and the modification cache was never refreshed.
A 2.x or early 3.0 store throwing deprecation errors or white screens after the host moved to PHP 8.
Default admin path, the install folder left on the server, storage inside the web root, and extensions with known SQL injection flaws.
Payment extensions built on deprecated PayPal or Stripe APIs that start failing when the provider retires the old endpoint.
Unindexed database tables, uncached category counts and uncompressed images making a modest catalog feel heavy.
[ How it works ]
Version, PHP compatibility, installed extensions and modifications, core file changes against a clean copy, and security basics. You get a written list of what is broken, risky or slow.
Work done on a staging copy of the store with real data, core edits moved into OCMOD or events, and every change kept in Git.
Deployed with a full backup ready to restore, then checkout, payments, shipping rates and admin re-tested on the live store.
[ What actually changes ]
I work on OpenCart 2.x, 3.0.x and 4.x, including stores that have been customized by several different developers over the years.
[ Example engagement ]
A 3.0 store with around forty hand-edited core files and several overlapping modifications. Changes moved into OCMOD and events, dead extensions removed, then updated to run on PHP 8.
Illustrative example of a typical engagement. Figures vary with the state of your systems and are not a guarantee of a specific outcome.
[ Free · 48 hours ]
Send me your store URL and OpenCart version. You get a written review of extensions, modifications, PHP compatibility and security, with the fixes ranked by risk.
[ Pricing ]
Tell me the number you have to work with. I'll tell you honestly what's achievable within it — and if it isn't enough, I'll say so before we start rather than halfway through.
Hourly rate $20/hoursmall jobs and ongoing work · fixed price for defined projects
Scope agreed in writing, price agreed in writing, before any work starts. No hourly creep and no invoice you haven't already approved.
For ongoing work — maintenance, monitoring, updates and small changes. Month to month, cancel whenever, no minimum term.
For a single bug, a short task or ongoing tweaks, where writing a full scope would cost more than simply doing the work. Billed in real time, reported in writing.
Budget too tight for the whole thing? I'll often suggest doing the highest-value part first and the rest later, rather than doing all of it badly.
[ Questions ]
$20 an hour for small fixes, extension conflicts and hourly work, billed for time actually spent. Anything with a defined outcome — an upgrade, a migration, a speed project — gets a fixed price agreed in writing before I start, so the number does not move halfway through.
Not automatically. OpenCart 4 changes how extensions and themes are built, so most 3.x extensions need replacing or rewriting. If your 3.0 store runs on a supported PHP version and your extensions are maintained, staying on 3.0 for now can be the sensible choice. I will tell you what the upgrade really involves before you decide.
Yes, this is one of the most common requests. I turn on error logging, find the exact files failing on the new PHP version, and fix or replace them rather than rolling PHP back.
Yes, for anything the marketplace does not cover well. It is built with OCMOD or events, documented, and installable through the extension installer like any other module.
Yes. I compare the files against a clean OpenCart copy, remove injected code, check the database and admin users, rotate credentials, and then close whatever let the attacker in.
Sometimes. If you keep paying for workarounds, need B2B features or want less server maintenance, Shopify or BigCommerce may cost less over time. If the store works and is maintained, staying is fine. I build on all of them, so I have no reason to push a migration.
Usually by quite a lot without a redesign: database indexes, caching, image compression, fewer third-party scripts and a CDN. I measure before and after so you can see what changed.
[ Related services ]
[ Guides on this topic ]
[ Let's talk ]
Send the store URL, OpenCart version and what is going wrong. You'll get a straight answer on scope, cost and timeline — same working day, from the person who'd actually fix it.