Changelog

What changed in each release of Abandoned Cart Recovery, in terms of what it means for you rather than which files moved.

1.1.1 — 3 October 2026

A fixes-only release. No setting, no table and no API route or field is added or changed, and what your store sends is what 1.1.0 sent, apart from the fixes below.

• Erasing works however many abandonments are still open. An erasure blanks the address, and a store could hold only one open abandonment with a blank address. So Remove everything held about a person failed on a store with two or more open abandonments, and erasing a person with an open one failed while an earlier erased one in that store was still open. An erased abandonment that was still open now closes as expired straight away, from either erasure screen, rather than staying open until its time ran out.
• Both erasure screens say so when the erasure does not answer. A timeout or a lapsed sign-in used to leave the button greyed out with no word on whether anything was erased. The screen now warns you, and the per-person screen reloads to show what is still held.
• An & or a quote reads as you typed it. Option names and values and the shopper's first name in the email, the store name on the unsubscribe page and the store names on the Episodes tab could show & where the text had &.
• Email wording you edit stays as you typed it. Wording on the Emails tab containing &, <, > or a quote gained a layer of encoding every time you pressed Save, so & became & and then &. It is stored as typed now. Wording that already picked up those characters keeps them until you correct it and save once.
• The language picker on the Emails tab no longer signs you out. On a store with more than one language, choosing another language opened the login page instead of that language's wording.
• The status banner explains a pass held for want of a position. It printed an internal name where the sentence should have been.
• The API refuses an OpenCart API user whose key has been emptied. OpenCart's own form will not save an empty key, but one emptied in the database by hand let in a caller who presented no key at all. Nothing changes for a caller presenting a real key.
• A coupon limited to the email's products is never made without them. Had an email ever reached the coupon with no product on it, the coupon would have been good on the whole cart; the send now fails instead. The preview's sample coupon also states the same last day a real one would get, which can run past Valid for (days) so it outlives the third email.
• The log says more when something fails. A pass or an email that fails writes the full error to the extension's log, a test email the mail server refused names the mail engine and PHP's own error, and an email that went out without its product pictures says so once per pass.

1.1.0 — 27 September 2026

Three additions. Nothing you had set changes: each new setting starts off, and what your store sends after the update is what it sent before.

• Preview an email, and send yourself a test. The Emails tab can now show any of the emails, in any of your languages, as the next pass would build it, with a sample shopper and basket. Send me a test mails the same email to the address on your own admin account, and nowhere else. A test counts toward nothing: not the daily limit, not the checks that stop a failing pass. How to use it.
• Conditions on the recovery coupon. Under Marketing sequence, the coupon can now also give free shipping, require a minimum subtotal before tax and shipping, and apply only to the products in the email that made it. The email states each condition under the code, read off the coupon it carries. What the coupon is.
• Find an abandonment by store or by address. The Episodes tab has an Address contains search, and on a store with more than one storefront a Store column and filter. The counts on the state pills follow the filter. The funnel still adds every store together.

1.0.0 — 24 September 2026

The first release. Everything in it is new, so the list below is what Abandoned Cart Recovery is rather than what changed.

• Two ways to email, chosen by you, and nothing sent until you choose. Reminder only sends one plain email with a link back to the cart. Marketing sequence sends up to three, with a recovery coupon from the second, and cannot be saved without your acknowledgement that you have a lawful basis for it. The decisions behind the wording are written out.
• Checkouts found from your own orders. Any checkout that reached the confirm step and was not paid is noticed by a scheduled pass, with nothing added to your storefront.
• A link that puts the cart back, straight to the checkout when everything went back and to the cart page, naming what could not, when something did not.
• An episode list of every abandonment, in nine states, with Resend, Stop emailing, Suppress and Lift suppression where each applies.
• A funnel for the last 30 days ending in one figure: orders placed by people who were emailed, within a fixed seven days of their last email.
• A backfill that reaches up to seven days before you installed, shows you the count per shopper before anything is sent, and sends each one the first email only.
• An unsubscribe that takes a button press, so a mail scanner cannot use it, and a suppression list per store that retention and erasure never shorten.
• A command line that runs the same pass without OpenCart's scheduler, which is the way to run it on OpenCart 4.1.0.4.
• A read-only JSON API, off until you switch it on, over the abandonments and the passes.
• It needs OpenCart 4.0.2.0 or newer, and every release from 4.0.2.0 to 4.1.0.4 has been through a full pass.

What an update keeps

Your settings come back, with the exceptions below. An update is an uninstall and then an install, and OpenCart deletes an extension's settings at the uninstall step. Abandoned Cart Recovery keeps its own copy of them and puts them back afterwards. Each store keeps its own, apart from module_abandoned_carts_api_enabled and module_abandoned_carts_diary_verbose_until, which Abandoned Cart Recovery reads once for the whole installation.

These are asked for again rather than put back:

• module_abandoned_carts_status — Whether the module is on is OpenCart's to set, and an extension putting it back for itself is an extension deciding it should be switched on. Switch it back on after an update with the Status switch on this extension's own settings screen, which Extensions > Modules opens with its Edit button: the module list itself has no switch.
• module_abandoned_carts_diary_verbose_until — Detailed logging comes back off after an update, the way a fresh install does. An upgrade is an uninstall and a reinstall, and putting a diagnostic window back is how a store ends up verbose months after the support exchange that asked for it ended.

A setting a release adds does not change what your store does. Its default is what Abandoned Cart Recovery did before the setting existed, so an update never asks you to go and set something to get back the behaviour you already had.

What this cannot tell you is whether a release changed how a setting behaves, as against whether it survives. Nothing derives that from the code, so it is written by hand: a release that changes an answer you relied on says so in its own entry above, as its own paragraph and never among what is new.