Service / OpenCart
OpenCart support for live stores. Critical issues get a senior reply in under 2 hours.
OpenCart rarely goes down. It leaks. A checkout that drops the shipping total, stock that disagrees with the warehouse, an admin so slow your staff stopped using it. A store in this state has usually been running unattended for years — still on 2.x or 3.x, old PHP, no staging, no repository, and a stack of OCmod patches nobody has read since the original developer stopped answering email. We take custody of that store: someone technical watches it, patches it, and answers when checkout breaks at nine on a Sunday evening.
<2h response
First reply from a senior engineer on anything critical. Weekends included. Everything else inside one business day.
Senior only
One senior engineer reads your OCmod stack and keeps your store. No juniors, no handoff, no explaining the thing twice.
No retainer
One incident at a time with a fixed quote, or month-to-month care. Nothing to sign before anything has been diagnosed.
Symptoms
The calls we get about unmaintained stores.
- Shipping revenue doesn’t match the carrier invoice and nobody can say where the gap comes from
- Sales dipped after an extension update and never came back
- Staff export everything to a spreadsheet because the admin is too slow to work in
- The warehouse gets picked an order for something you had already sold out of
- Nobody at the company knows how the store works, and the agency that built it has gone quiet
- You find out the store is down when a customer emails you, not before
Failure classes
Six OpenCart failures, and the tell for each one.
The six below share a habit: the code that is failing isn’t the code sitting in your file tree. OpenCart fails quietly — a patch that stopped matching, a total that never got written, a query that locks a table at four in the afternoon. Each one has a tell you can check yourself before you call anyone. Find it, send it with your triage, and we start a step ahead.
OpenCart OCmod error, or vQmod not working after an update
OCmod and vQmod don’t edit your files. OCmod merges active patches — any file, not only controllers — into copies under system/storage/modification (system/modification before 2.3) when someone hits Refresh in Extensions > Modifications, not on every request, and the patch XML lives in the oc_modification table, not your file tree. vQmod is separate, with its own cache, XML and log. A stale search string is skipped and logged NOT FOUND in ocmod.log. Two patches on one line apply in sequence: the second searches what the first rewrote. We map what actually runs, then rebuild from version control.
OpenCart admin not loading, or a 500 error with no message
A blank admin or a 500 is PHP hitting a fatal with display_errors off. OpenCart buffers the whole response, so a fatal late in rendering looks the same as one at boot. Read the PHP error log first: OpenCart’s own error.log holds warnings and caught exceptions, not the fatal itself. Usual causes: an extension removed but still registered in oc_extension, storage paths left on the old host after a move, storage permissions, memory exhausted on a long admin list, or a non-static method called statically — fatal from PHP 8.0. We read the log, then fix what put you out.
OpenCart checkout not working after an extension conflict
The loud version throws an error at the payment step. The expensive version completes. checkout/confirm loops the enabled total extensions in sort_order and calls each one’s getTotal(), and the shipping line is written by the total/shipping extension reading the quote your shipping method left in the session. Disable that total, lose the session quote, or patch confirm so the loop skips it, and the order saves with no shipping row and no error. Payment extensions sit outside that loop — their sort order only orders the payment list. The tell is in your data: match oc_order_total against what the carrier actually charged over the last 90 days and find the orders with no shipping row.
OpenCart slow: category pages, search and product saves
Slow OpenCart is usually a short list of known queries plus missing caching, not an undersized server. Category pages with product counts run a COUNT per subcategory across oc_product_to_category and oc_category_path on every request. Search runs LIKE '%term%' over oc_product_description, which no index helps. The admin product list counts the filtered catalog on every page load, and tool/image resizes synchronously, so the first request for a missing thumbnail waits on GD. A product save deletes and reinserts rows across description, store, category, layout, option, discount, special and SEO-url tables. We read the slow query log, confirm OPcache survived the last host move, then fix queries and cache what is safe to cache.
OpenCart stock synchronization and ERP integration drift
Stock that disagrees with the warehouse is rarely a stock bug. Two systems both write oc_product.quantity on their own schedules — and if you sell variants, option-level stock sits in oc_product_option_value.quantity, which most ERP feeds never touch. OpenCart only moves stock when an order crosses into the statuses listed in your Processing and Complete settings, which are rarely the ones you assume, and only for lines whose product has subtract set — then it restocks on the way back out. Failed API calls get retried, so the same order decrements twice. We decide which system owns the number, make the sync idempotent, log every write, and reconcile against the warehouse before anyone changes code.
OpenCart PHP 8 compatibility on 2.x and 3.x stores
Hosts move; 2.x and 3.x stores don’t. On 3.x, core mostly survives PHP 8 from 3.0.3.8 onward, and what fatals is third-party extensions and theme overrides. On 2.x, core is part of the problem: the stock encryption library calls mcrypt_*, gone since PHP 7.2, so a 2.x store is either already patched or already broken before PHP 8 is even the question. PHP 8.0 removed PHP 4-style constructors and made calling a non-static method statically fatal; 8.1 has mysqli raise exceptions instead of warnings; 8.1 and 8.2 fill the log with null-argument and dynamic-property deprecations. We test your actual modification set against the target version on staging and keep every change in version control.
Plans
OpenCart support and maintenance, three ways to buy it.
Nobody hands a stranger their store on day one. So start with the free triage, then buy OpenCart technical support from the same engineers whichever way fits: Monitor if the store works and you want it to stay that way, Engineering if there is a backlog as well as a store to keep alive, Emergency if something is broken right now.
Monitor
$595 /month
Someone technical is watching the parts of OpenCart that fail without telling you: the order flow, the PHP error log and the modification cache.
- Uptime, PHP error log and order-flow checks that alert us, not you
- Core, extension and theme updates, staged before they go live
- Backups we restore on purpose, to prove they work
- Up to 4 hours of OpenCart fixes a month, OCmod cleanup included
- Priority email support, under 2 hours when it’s critical
FIRST MONTH REFUNDABLE
Start with MonitorEngineering
$1,950 /month
A senior engineer who already knows your OCmod stack, your template overrides — .tpl on 2.x, Twig from 3.0 — and your integrations, shipping from your backlog every week.
- Around 20 senior engineering hours a month
- Everything in Monitor
- OCmod and vQmod patches folded into modules you can read
- Payment, carrier, ERP and feed integrations that survive updates
- Shared Slack channel, weekly written update
UNUSED HOURS ROLL OVER ONE MONTH
Book a fit callEmergency
$500 from, per incident
Checkout is failing, the admin won’t open, or the store is compromised right now. No retainer, no onboarding, no waiting on a contract.
- First reply from a senior engineer in under 2 hours, Mon–Sun
- We diagnose before you pay anything
- Fixed quote before we touch the store
- Written post-incident report you keep
- 30-day warranty on the fix
CAN’T FIX IT? YOU PAY NOTHING
Request dispatchMonth to month, month one refundable, no retainer for one-off work. Big catalogs, multi-store setups and 2.x stores needing PHP work are quoted once we have read the code, not guessed at on a call.
How it works
From a symptom to a fix that holds.
Send the URL and the symptom
Use the triage form. An order number and roughly when it started is enough. No call first, no discovery deck.
A senior engineer opens it
Same day, usually. We go through ocmod.log, the error log, the modification cache and the order table before offering an opinion about any of it.
A written diagnosis, free
What is actually broken, what it is costing you, and a fixed quote to fix it. Yours to keep whether you hire us or not. If doing nothing is the cheaper call, it says so.
We ship it, then keep watching
Staging, review, deploy, monitoring. It ends with a written postmortem and an alert on the thing that failed, so next time it raises a flag instead of going quiet for months.
From the field
The 8% of checkouts that shipped for free.
Roughly 8% of checkouts came through with no shipping cost on them. Nothing errored, nothing alerted, and the orders looked ordinary in the admin. The store paid that freight out of its own margin for months, until somebody lined a run of carrier invoices up against the totals in the admin and found the gap.
Two OCmod extensions were patching the same checkout controller. Both were merged into the modification cache in the order OpenCart read them, and the second searched for a line the first had already rewritten — so that operation was dropped and the shipping total was never written. It left a NOT FOUND line in ocmod.log. Nothing in the error log, nothing on screen.
Both patches now live in one event-based module you can read top to bottom. Order totals were reconciled against the carrier invoices, so the gap could be counted instead of estimated. The modification cache now rebuilds only from code in version control.
The stack
What we read before we form an opinion on an OpenCart store.
OpenCart is small enough to read end to end, which is exactly why it gets abused. Nothing stops an extension from rewriting a core file behind your back, so before anything changes we work out which code actually executes — not which code is in the repository. Here is what we go through on a store we have never seen, on 2.x, 3.x and 4.x.
The modification layer
- Every OCmod and vQmod patch found, and where the XML lives:
oc_modification, orvqmod/xml - Modification cache rebuilt only from code in version control,
system/storage/modificationon 2.3–3.x - Skipped operations read out of
ocmod.log, where OpenCart records them at refresh time - Template overrides and theme fallback to
default:.tplon 2.x, Twig from 3.0, events over core edits - What 4.x changed: namespaced classes,
extension/<vendor>/,.route separator, no OCmod until 4.1
Versions, PHP and performance
- PHP 8.0–8.2 on 2.x and 3.x:
mcryptgone since 7.2, static calls fatal at 8.0, mysqli throwing from 8.1 - OpenCart 2.x: no upstream releases and no security fixes for years, so every fix is ours
- Catalog, search and admin query profiling against the slow query log, with OPcache checked first
- Product saves that fan out across store, language, layout, option and SEO-url rows
- Order totals reconciled against gateway and carrier invoices
Questions
What store owners ask us about OpenCart support.
How much does OpenCart support cost?
Monitor is $595/month. Dedicated engineering capacity is $1,950/month. A one-off emergency starts at $500 per incident, with a fixed quote after a free diagnosis and no retainer required. Anything larger gets a fixed quote too, once we have read the code — the OCmod stack decides most of the cost and you cannot see it from outside. And if we read the store and find nothing worth fixing, the triage note says so and you pay nothing. Diagnosis comes before the invoice.
How fast can you start if our OpenCart store is down right now?
First reply from a senior engineer in under 2 hours on anything critical, Mon–Sun. Everything else, one business day. Emergency work usually starts the same day, once we have access and straight answers: SSH or SFTP, the database, an admin login, and the name of whoever last changed something. We run Europe and UK hours with weekend on-call for incidents, and we don’t sell a 24/7 phone desk or an uptime percentage written into a contract, because neither is something we could keep.
Do you still support OpenCart 2.x, and will it run on PHP 8?
Yes to both, with a caveat. Plenty of 2.x stores take orders every day and don’t need rebuilding; what they need is someone who knows the version — no upstream releases or security fixes for years, and a modification stack nobody has read in just as long. Stock 2.x does not run on PHP 8 as shipped: the encryption library uses mcrypt, gone since PHP 7.2, plus PHP 4-style constructors and static-call patterns that are fatal from 8.0. That is compatibility work on core as well as extensions, not a flag flip. On 3.x the job is lighter. Staying on 2.x long-term is a security decision, and we say so plainly.
Can you clean up a hacked OpenCart store?
Yes, and the cleanup is the second step. First we find how they got in, because reinstalling files over a live backdoor only buys a quiet week. On OpenCart it is usually a file-manager extension left open, an install/ directory nobody deleted, a guessable admin path, or credentials in a backup sitting in the web root. The persistence is what catches people: an infected modification XML re-injects itself every time the cache rebuilds, alongside appended code in index.php, PHP dropped in the image directories, and an admin user added straight into oc_user. You get a written timeline of what was touched.
Can you work alongside our existing OpenCart developer or agency?
Yes, and that is how much of this work runs. We take the jobs that can take production down — checkout, upgrades, payment and ERP integrations — and hand the changes back documented and reviewed, so your team can carry them without us. We also work white label for agencies: you keep the client relationship, we supply the senior OpenCart engineering behind it, and we stay off calls with your client unless you want us there.
Can I hire an OpenCart developer from you for a few hours a month?
Yes. Monitor includes up to four hours of fixes a month, which is the smallest way in. Engineering is around twenty senior hours and works like having an OpenCart developer on the team without hiring one. Custom modules, theme builds, 3.x to 4.x migrations — there is no in-place upgrade, since namespaced code and the new extension/ layout mean every module and patch gets rebuilt — and the stay-or-migrate question live on our OpenCart development page rather than this one, because that is build work rather than keeping a live store running.
Field notes
Real incidents, written up.
POSTMORTEM
The Black Friday incident where our on-call saved $340k
Alert at 3:17am UTC. Database exhausted, load balancer sending traffic the wrong way. The full timeline.
store down · recovered in 41 min
POSTMORTEM
The Magento upgrade that took a B2B site offline for 4 days
An upgrade run straight against production, and the four days it took to get the store back. The full write-up.
store down · 4 days
DEV & OPS
Core Web Vitals for ecommerce, minus the plugin snake oil
What actually moves LCP and INP on a store, and which plugins only move the score.
field guide · measured, not guessed
Related
Free triage
Send us the store nobody is watching.
Give us the URL, the error text if you have it, and roughly when it started. A senior OpenCart engineer reads it and comes back with a first take on what is actually failing — inside two hours if the store is actively broken, inside one business day otherwise. It is free, nothing gets signed, and if the store turns out to be fine, the note will say so.