Changelog

What changed in each release of Delivery Date, described by what it means for you rather than by which files moved.

1.6.1 — 3 October 2026

A fixes-only release. It carries everything in 1.6.0 below.

• A name with an & in it reads as you typed it. A window called Sat & Sun, a calendar name, a product name or a customer's own name and address used to come out as Sat & Sun in the checkout picker, the moved-date notice, the confirmation email, the order screens, the day sheet and its printout. Bookings made before the update print correctly too; nothing needs re-saving.
• The Wording box keeps what you type. Each Save used to add a layer of encoding to an & or a quote in the sentence, so & became &, then &. It is stored as typed now. A sentence saved before the update keeps whatever it already held: if yours has an &, <, > or a quote in it, open the box once after updating and correct what you see there.
• Switching language in the Wording box no longer signs you out. On a store with more than one language, picking another one used to land on the login page.
• The day sheet's CSV cannot run a formula in your spreadsheet. A cell a customer filled in that starts with =, +, - or @ — a phone number such as +44…, say — is written with a ' in front of it, and names and addresses arrive without & in them. See the planner's limits.
• An API user with an empty key is refused. OpenCart's own form will not save one, but a row edited by hand can hold one, and it used to let in a caller who sent that username and no key at all.

Two corrections to the documentation ride along. A day changed from the order page keeps the new day only: the day the customer picked survives in Delivery Date's own log line for the change, not on the booking, which 1.5.0's entry below now says. And the module's Status switch, which an update turns off, is on Delivery Date's own settings screen rather than in the module list.

Nothing to do on update beyond the Wording check above. No setting, table or API field changes.

1.6.0 — 2 October 2026

A read-only JSON API, off until you switch it on. Your carrier's or warehouse's own system can read each order's delivery promise: the day, the window as the customer was told it, the shipping method, whether it moved when payment confirmed, and whether it still stands — an order you cancel reads as released at once. It can ask for only what changed since a moment. It cannot book or move a delivery, and calendars, windows and capacity are not readable through it. Switch it on under API on the default shopfront's settings; a caller signs in as an OpenCart API user under System → Users → API. The API lists every field, and limits and guarantees says what it cannot do.

Nothing to do on update. One new setting, the API switch, which arrives off. The update adds one column and one index to the bookings table; bookings made before the update carry no "changed" date until they next change.

1.5.0 — 28 September 2026

The delivery day is now on core's printed invoice and shipping list, under the shipping method, for every order on the sheet: the day and the window, or the sentence saying no day could be offered. A packer holding the shipping list can see which day the parcel is for. There is no was … line on paper, because an invoice can go in the box to the customer. An order with no booking prints exactly what OpenCart printed before.

A shipping method's calendar can be limited to some customer groups. Tick them under Offered to on the calendar, and a customer outside those groups gets the store calendar for that method, exactly as if the method had no calendar of its own. That is how trade customers get a Saturday retail ones do not; see the guide. Nothing ticked means every group, so every calendar you already have behaves as it did. The store calendar cannot be limited, because it is what everybody falls to. Saving a calendar now also writes a line to Delivery Date's own log naming the ticked groups, by number and never by name; see what Kyvero extensions log.

A firm booking can be given another day from core's order page. The Delivery Day block there has a Change button: pick a day and a window from the order's own calendar, and save. It is how an order in the planner's red banner finally gets a day. It never books a closed date, refuses a full window unless you tick Book it even if the window is full, and tells the customer nothing; add an order history line with Notify ticked for that. The booking keeps the new day only; the day the customer picked is in the diary line for the reassignment. The planner itself stays read-only. See the planner's limits and the guide.

Read this if more than one user group handles delivery days. Modify on extension/delivery_date/sale/planner used to mean nothing, and now means may change a booking's day. The update gives it to the user group that installs Delivery Date and to no other, so a group that only had Access on the day sheet still reads it and sees no Change button. Tick Modify for any other group that should change days at System → Users → User Groups, and have those users log out and back in. And check that no group you meant to keep read-only already had Modify ticked on that route, because from this release it does something.

1.4.0 — 21 September 2026

The settings screen now says what OpenCart 4.1.0.1 has taken away. On that release OpenCart's own guest checkout answers a PHP warning ahead of its reply and the browser cannot read the reply, so a guest who presses Continue sees nothing happen and never reaches the step the date picker is part of. An extension cannot repair this, and nothing in Delivery Date was broken, but a store owner on that release should be told rather than left to find a picker that never appears and assume the fault is ours. The screen names the release, says a guest cannot get through and says a customer with an account is unaffected. See limits.

4.1.0.1 has come off the tested list for the same reason, and 4.0.2.1, 4.0.2.2 and 4.0.2.3 are on it; all three have had a full pass. The list now runs 4.0.2.0 through 4.1.0.4 with that one gap.

1.3.0 — 21 September 2026

OpenCart 4.1.0.4 is now a tested release. The full pass (archive, install, use, upgrade over itself, uninstall) has been through a 4.1.0.4 store, so the compatibility list runs 4.0.2.0 through 4.1.0.4 and the settings screen stops calling that release untested.

That release has a fault in OpenCart itself which stops every scheduled task on the store; see requirements. It costs Delivery Date nothing. Holds expire by predicate, releases follow the order status, and the capacity count is worked out when it is asked for, so nothing here ever waited on a schedule. Nothing else changes.

1.2.0 — 21 September 2026

Everything Delivery Date puts in your database about a person is now published field by field, with what removes each one: table, column, why it is there, how long it is kept, and what an erasure does to it. It is at https://docs.kyvero.dev/delivery_date/reference/personal-data/. The page is generated from the extension's own declaration rather than written beside it, so it cannot describe a column the code does not have or miss one it does. In short, six of the seven tables are your own configuration (your calendars, your windows, their names, your per-product preparation times), and the seventh is the booking: which day and which window one order is being delivered in. There is no name, no address, no telephone number and no email address anywhere in it, which is why the page reaches a person by joining OpenCart's own order rather than by matching a column of ours.

Two things on that page are worth reading even if you read nothing else. The window name and the shipping method on a booking are frozen copies, taken in the order's own language on the day the customer chose them. Renaming a window changes what the picker offers from then on and never changes what somebody was already told, and a correction is made on the window rather than on the booking. And a booking whose order you have since deleted is unlinked: nothing on it names anybody, and there is no longer an order to reach it through, so an access request cannot find it and the page does not claim it is erasable. The remove-everything button below is the only thing that reaches one.

A new screen answers what do you hold about me for one named person. On Customers → Personal Data you enter an email address and get back every holding: from this extension, from any other Kyvero extension you have installed, and from OpenCart itself. Each extension answers for itself and nothing there decides anything on another's behalf. It also prints what OpenCart's own account-deletion flow does and does not do on the release you are running; read that before you promise anybody anything. There is a Remove it button on the same screen, which takes what each declaration says an erasure takes and keeps what it says is kept, with the reason shown against every line it kept. Here that means every booking on every order that person placed goes, and nothing of your own configuration is touched. Looking a person up, or removing what is held about them, needs OpenCart's own Modify on customer/customer: reading out everything a store holds about one named person is at least as privileged as editing their account.

The settings screen also gains a button that removes everything this extension holds about everybody, not one person. It is deliberately separate from uninstalling. Uninstalling deletes nothing at all, on purpose: an OpenCart update is an uninstall followed by an install, so an extension that dropped its tables on the way out would destroy your whole delivery calendar on a routine upgrade. Removing what is held is therefore something you do on a screen, while you can still see what you are about to lose. It prints the plan first (the table with a real count beside it), reports what went rather than saying success, and cannot be undone. What goes is every booking, including the ones whose orders have been deleted, which nothing else can reach. What stays is every calendar, window, window name, preparation time and setting, none of which is about anybody.

The new screens come with two permissions, and clicking + gives them to your own group. Customers → Personal Data is access on extension/delivery_date/customer/personal_data with OpenCart's own Modify on customer/customer behind the act itself; the remove-everything screen carries access and modify of its own on extension/delivery_date/customer/purge, so you can hand somebody the per-person screen without handing them the one that empties the lot. For any other group, tick them at System → Users → User Groups, and log out and back in.

1.1.0 — 10 September 2026

One sentence a customer reads is now yours to write, and three copies of it are gone. There is no delivery day for this order yet, we will be in touch was worded four separate ways: once at the checkout, once in the order history, once in the confirmation email and once on the customer's own order page. It is one sentence now, written on the settings screen under Wording, per language, and said in all four places.

This is the one visible change, so read this if you edited our language file. Three of those four wordings differed slightly from each other, and the one that survives is the order-history wording: We can't schedule a delivery day for this order yet. We'll contact you to arrange one. If you were happy with the other three as they were, or had edited them in extension/delivery_date/catalog/language/, put your own words in the Wording box instead. An update replaces our language files and always did, and the box survives one.

Delivery Date can also now read a translation of its own strings once one exists: it works out which of the languages it ships your store should be served, rather than assuming your language code is spelled the way our directories are. It still ships English and only English, so with one language shipped that question has one answer and a single-language store is not asked anything. Your window names are unaffected; those are yours, per language, and always were. See Limits and guarantees.

1.0.0 — 26 August 2026

The first public release. There is no previous version, so nothing below is a change. This entry is the baseline every later one is measured against.

What ships: a day-and-window picker in the shipping-method block your theme already renders, caps per window and per weekday, closed dates and a cut-off and a horizon previewed on the screen you set them on, a calendar per shipping method, preparation time per product on core's own product form, and the day sheet at Sales → Delivery Days with its print document and its CSV. What it does not do is the shorter list; read it first.

It runs on OpenCart 4.0.2.0 and 4.1.0.3, and refuses to install below 4.0.2.0 rather than half-working. See requirements and install.

What an update keeps

Your calendars, your slots, your closed dates, your per-product preparation times, every booking and the Awaiting Delivery Date status are never touched by an update: they live in tables nothing here ever drops.

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. Delivery Date keeps its own copy of them and puts them back afterwards. They are one set for the whole installation rather than one per store, apart from module_delivery_date_lead_basis and module_delivery_date_copy, which each store keeps its own of.

These are asked for again rather than put back:

• module_delivery_date_status — Whether the module is on is OpenCart's to set, and an extension putting it back for itself is an extension deciding your storefront should start promising delivery days. 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_delivery_date_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 Delivery Date 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.