OpenCart store broken? We read the log and fix it.

Every project gets a fixed written quote. Send a short brief on WhatsApp and I reply within one working day with scope, price and timeline. A batch of related bugs, or one deep root-cause like post-upgrade fallout or a payment-callback failure, is a Bug-Fix Sprint with full regression testing. Fixed quote on request. You always get the quote before any work starts.

Emergencies, a blank white storefront or a broken checkout, get a first response inside 4 hours. Most standard single bugs (an Undefined index notice, an OCMOD conflict, a 404 SEO URL) are fixed and verified within 24-48 hours. We always read your storage/logs/error.log first so the triage is accurate, not a guess.

Staging first, always. We clone your store to a staging environment, turn full error logging on, and reproduce the bug there, never debugging blind on your live storefront. Once the fix is tested, we deploy it to live, refresh the vQmod/OCMOD modification cache, clear the OpenCart cache, and verify the fix in production with you. If you don’t have staging, we can spin one up.

Yes. Every fix is reproduced and tested on a clone before it touches production, and ships with a regression check across cart, checkout, payment and admin so one fix never silently breaks another flow. Where possible we patch through a clean OCMOD or vQmod modification rather than hacking core files, so the change is reversible and survives future updates.

A blank white page (WSOD) almost always means a PHP fatal error is being hidden. The cause is in storage/logs/error.log, commonly Fatal error: Uncaught Error: Call to a member function ... on null, a missing class after a half-finished extension install, a memory-limit exhaustion, or a broken vQmod/OCMOD modification. We tail the log, trace the controller and model, and patch the real cause, we don’t just hide the error with display_errors off.

Notice: Undefined index (and on PHP 8, Warning: Undefined array key) appears when a template or controller reads an array key that wasn’t set, usually after a PHP version bump or a theme/extension that wasn’t written for your version. They flood the header, product and category pages. We harden the controller data and templates so the keys are always defined, then quiet the log, without masking genuine errors.

Yes, this is one of the most common OpenCart bugs. When two modifications patch the same core file, the XML search/replace can silently fail or apply in the wrong order, breaking a page. We inspect the vqmod/vqcache output (or the merged OCMOD modification.xml), find the clashing rule, and re-order or rewrite the search/replace so both extensions coexist. We then refresh the modification cache so the fix actually loads.

Yes. Orders stuck in Pending usually mean the gateway’s IPN/callback never reached OpenCart, or it did but the signature check or order-status mapping failed, we see this with PayPal, Stripe, Razorpay, SagePay and Authorize.Net. We verify the callback route resolves (not a 404), confirm SSL and the expected headers, check the IPN/webhook signature, and fix the order-status mapping so paid orders flip to Processing.

OpenCart friendly URLs 404 when the rewrite chain breaks, commonly a missing RewriteBase in .htaccess, the SEO URL setting left off, missing seo_url rows after a migration, or $_SERVER['REQUEST_URI'] behaving differently on a new server/PHP version. We restore the rewrite block, fix the SEO PRO / SEF configuration, and re-seed any missing seo_url keywords so your indexed URLs resolve again.

Yes, post-upgrade fallout is a big part of what we fix. Moving to 3.x (or onto a new PHP 8 host) often breaks a theme or extension that relied on old behaviour: Twig template errors, undefined-index notices, broken OCMOD modifications, or a payment module that no longer matches the new API. We map what broke, fix the templates and modifications, and bring extensions up to the version they were built for. This usually fits a Bug-Fix Sprint.

Yes. Wrong totals after switching currency or changing a tax class are usually rounding drift, a stale exchange rate, or a tax rule applied to the wrong geo zone. We trace the calculation through system/library/cart and the tax classes, reconcile the math against expected totals, and confirm the cart, checkout and order confirmation all show the same figure across every currency you sell in.

Yes. A Quick Fix carries a 7-day warranty on that specific bug, if it recurs, we fix it again at no charge. A Bug-Fix Sprint includes 14 days of post-fix coverage. Because every fix is reproduced on staging and regression-tested before deploy, recurrences are rare. For ongoing peace of mind on a live OpenCart store, an Emergency / Retainer keeps you in a priority queue.