OcBox Cart Lifetime: guest cart lives 30 days instead of 1 hour, no 1213 Deadlock, no cleanup on every page view for OpenCart and ocStore

OcBox Cart Lifetime: the guest cart lives 30 days instead of one hour, no more 1213 Deadlock errors and no cleanup on every page view for OpenCart and ocStore

This is a free Community Edition module. It fixes two pains that share a single root. The first one: in stock OpenCart, the cart of a non-logged-in buyer lives exactly one hour, so a person who dropped by in the morning and came back in the evening sees an empty cart. The second one: cleanup of old carts runs on every page view, and under peak load it causes row-level deadlocks (database error 1213) that make «Add to cart» fail with a blank page. The module stretches the guest cart lifetime to 30 days with a sliding window, runs cleanup rarely and in small batches, and merges the returning buyer’s old cart with the current one without duplicates. Free, no ionCube, no domain binding.

Quick links: Two pains, one root · What the module does · Database index with one click · Honest boundary of the module · Compatibility

Two pains from a single root, in plain language

Pain number one, visible to the shop owner. In stock OpenCart, the cart of a buyer who has not logged in lives for exactly one hour. The person adds a product, goes to ask their spouse, comes back in the evening, and sees an empty cart. They do not start over, they go to a competitor. For goods that are chosen slowly (kitchens, furniture, bicycles, courses, insurance), this is money straight out the door. OpenCart settings have no option for this, so most shop owners never find out this is how it works under the hood.

Pain number two, visible to the developer. The same old-cart cleanup is triggered by the OpenCart core on every page view in the catalog. The SQL query is written in a way that prevents the database from using an index, so it scans the full cart table and holds a lock on a wide row range the entire time. On a busy shop, a parallel «Add to cart» request queues up behind this cleanup, and the two deadlock each other. The database log fills with error 1213 (Deadlock found when trying to get lock), and in that very moment the buyer sees a blank page instead of the product they just added. Gets worse during peak hours, during catalog imports from an ERP, and when search-engine bots crawl the site.

Both problems have the same root: the core cleans carts in the wrong place, at the wrong frequency, with a query that locks the table. Fixing it means detaching cleanup from every page view, shrinking the window it touches at a time, and adding a proper date index to the cart table.

What the module does, point by point

Below are all the behaviour changes the module introduces to the cart. Each can be turned on or off independently, so you choose how far you want to move from stock OpenCart.

Guest cart lifetime stretches to 30 days with a sliding window

✓ The cart lives for 30 days, and the clock resets with every action of the buyer
By default a non-logged-in buyer’s cart lives for 30 days (the value is adjustable between 1 and 365 days). The window is sliding: every time the buyer comes back, browses, adds a product, or changes a quantity, the clock resets. As long as the person keeps dropping by, the cart waits for them. Abandoned carts behave the same way: they stay available for recovery and analytics rather than vanishing one hour after the buyer closes the tab.
⚠ Without this: the cart is wiped after 60 minutes, and a buyer who comes back after lunch starts from zero. Half of them do not start again.

A returning buyer’s old cart merges with the current one, no duplicates

✓ Old and new carts combine into one; identical lines add up in quantity
When the buyer comes back (new session, new browser), the module locates their previous cart by a signed cookie marker and merges it with the current one. Identical lines with identical options add up in quantity instead of becoming two rows. Different lines sit next to each other. Logging in behaves the same way: the guest cart is added to the customer cart, instead of one of them disappearing.
⚠ Without this: the customer either has two «phone» rows instead of four, or the guest cart vanishes together with the logged-in customer and the purchase starts from scratch.

Cleanup runs rarely and touches only a limited batch at a time

✓ One cleanup pass per roughly a thousand page views, and it only touches a few hundred rows at a time
Instead of firing a wide DELETE on every page view, the module runs cleanup roughly once per 1000 page views (frequency is configurable). Each pass touches a bounded batch (500 rows by default, configurable), uses the date index, and holds the lock for milliseconds instead of seconds. Parallel «Add to cart» calls no longer queue behind it and no longer hit 1213 Deadlock.
⚠ Without this: during peak hours the database log is swamped with 1213 errors, the buyer clicks «Buy» and sees a blank page, and the shop owner cannot figure out why the abandoned-cart ratio jumped in analytics.

One click creates the recommended database index

✓ A «Create index» button right on the settings page, no need to open a DB editor
Fast date-based cleanup needs an index on the date_added column of the cart table. The stock OpenCart schema does not have one, and most shop owners will not add it by hand through a DB editor. The module shows the state of the table on a status panel, and when the index is missing it offers to create it with a single button. Safe on a live shop: creating an index on the cart table takes a few seconds even with hundreds of thousands of rows.
⚠ Without this: a healthy cleanup frequency is still noticeably slower, because the database scans the whole table instead of jumping straight to the oldest rows. On a big table that is a 10x difference.

Status panel: everything happening with the cart table is visible at a glance

✓ Table state, index presence, row count, age of the oldest row: on one page
The settings page shows: whether the recommended index is created, how many rows are in the cart table right now, the age of the oldest row, when cleanup last ran and how many rows it took. You can tell at a glance that the module is actually doing its job and how much work it is taking off the core. If something is off (for instance, cleanup has never run since install), it is visible, not hidden inside the database.
⚠ Without this: the shop owner has no way to check how many guest carts the database holds right now and when it was last cleaned, other than running a query through a DB editor.

Settings: lifetime, cleanup frequency, batch size

✓ A handful of fields in the usual OpenCart admin, no code or database edits
On the settings page: a toggle to enable or disable the module, the number of lifetime days (30 by default), cleanup frequency (around once per 1000 page views), batch size per pass (500 rows by default). Everything is done with checkboxes and numbers, with no edits to the core cart.php file and no manual SQL. For a shop with special needs (say, a long purchase cycle) all values can be nudged up or down, and the module keeps working.
⚠ Without this: any behaviour change means a hand edit of the core file, which the next OpenCart update will overwrite.

Honest boundary of the module: what it does and what it does not promise

Written plainly, because we do not need customers who show up later saying «you promised there would be no errors». The module makes database row deadlocks (1213) rare, not completely impossible. It removes the three main causes: cleanup on every page view, a wide lock range, and a missing index. But fully eliminating 1213 Deadlock is only possible by changing the database transaction isolation level (READ-COMMITTED instead of the stock REPEATABLE-READ), and that is a my.cnf change and a conversation with your hosting, not a module. The vast majority of shops will not need that: after this module, 1213 errors move from «several times a day» to «several times a month», often completely out of sight.

What this means in plain words

Previously, to make OpenCart keep carts alive for more than an hour and not torment the database with its cleanup, you had to edit the core file system/library/cart/cart.php, rewrite SQL queries by hand, build a signed cookie separately, open a DB editor and add an index yourself, and hope the next OpenCart update would not wipe all that. OcBox Cart Lifetime packs this into a single module that installs via OCMOD, has a settings page in the admin, and creates the index with a button of its own.

Who this module is for

For any shop on OpenCart 3.x or ocStore 3.x that has seen at least one of three things: a customer complaint that «my cart keeps disappearing», analytics showing an unnaturally high abandoned-cart ratio over a short dwell time, or 1213 Deadlock entries in the database log. Especially useful for shops with a long consideration cycle (furniture, kitchens, bicycles, courses, insurance, auto parts chosen by compatibility), where buyers typically return another day.

Compatibility

The module works on OpenCart 3.0.x and ocStore 3.x, PHP from 7.0 to 8.3, MySQL 5.7+ and MariaDB 10+. Installs via OCMOD into system/library/cart/cart.php, so it is compatible with most themes and third-party cart modules (Prime, UpStore, CyberStore, Chameleon, LuxShop, NewStore and others). No ionCube, no domain binding, no external dependencies. Compatibility with other modules that also patch cart.php can be reviewed on the modification refresh page.

How files are delivered

The module is free and delivered immediately upon download from this page. No keys, no activation, no registration: unpack the archive, upload the upload/ contents to the shop root, refresh modifications in the admin (Extensions → Modifications → Refresh), open the module settings and click «Create database index». That is all.

Recommended paid OcBox modules

Smart Related $30, related products	SEO FAQ AI $30, AI FAQ + Schema.org	AI Product Editor $50, mass editing
Image Pro $15, WebP, watermark	Filter $30, smart filter + SEO	Category Manager $15, visual category manager
AI Smart Search $200, AI search with synonyms	AI Chat $100, AI assistant 24/7	AI Photo Studio $50, AI photo processing
PaymentHub $80, payments hub	ShippingHub $80, shipping hub	SmartOrder $30, fast checkout
ShippingRules $30, shipping rules	AI Megareports $20, reports and Telegram digest	Product Bundles $30, product bundles
Simple Super Search $15, fuzzy search without Sphinx

Subscribe to our channel: t.me/ocboxchannel