Changelog

What changed in each release of Product Configurator, in terms of what it means for you rather than which files moved.

1.6.0 — 3 October 2026

A rule's THEN side can now name an option of any type. The rule builder offered only dropdown, radio and checkbox options as targets, so the rule these pages have always used as their first example, show the option Engraving text, could not actually be written. The target list now carries every option on the product: a text box, a text area, a file upload, a date. The WHEN side keeps the three types it had, because a condition has to match a value you set in advance.

A rule with an unfinished condition is no longer saved without it. A rule with one condition left on choose an option used to be stored with the conditions that were finished, so hide X when A and B became hide X when A and hid X for more customers than you meant. The whole rule is now dropped, the way a rule with no verb or no target already was. A save also now stores a product's rules all at once: one that fails part way leaves the rules the product had, not half of the new ones.

A product form without the Configurator tab no longer clears a product's rules. If an admin theme or another extension rewrites the product form so the tab cannot be placed on it, saving a product from that form used to wipe the rules it had. It now leaves them exactly as they were.

Rules of a product deleted while Product Configurator was uninstalled are cleared when you install it again. Nothing was listening while it was off, so those rules stayed behind, and on some databases they attached themselves to the next product given the same id. Installing, which is also what every update does, now removes them.

Text a customer typed into an option is now handled strictly as text. When a customer reopened a configured cart line with Change options, what they had typed into a text option was placed into the product page in a way the server could read as an instruction. It is now passed to the page as plain data only. If you run a store where customers type free text into options, update. An option value or a typed answer containing & also no longer comes back as & on a swatch's name or a reopened line.

Smaller things on the admin side. Pressing Replace with that product's rules before picking a product now says Pick a product from the list first. instead of doing nothing, and the tab says so when the rules could not be fetched. The warnings no longer report a required option as a dead end because of a rule that can never fire anyway. The two personal-data screens under Customers now say when an erasure or a removal got no answer, rather than leaving the button greyed out.

Nothing about your rules or your settings changes on upgrade. No setting is added, no table changes and the storefront looks the same.

1.5.0 — 30 September 2026

Copy rules from another product, on the Configurator tab. Under the rules, pick a product by name and press Replace with that product's rules: the tab shows that product's rules in place of its own, and OpenCart's own Save stores them. Until then nothing has changed, so leaving the form undoes it. It replaces rather than adds, and asks first when the tab already holds rules. Pick a variant and you get its master's rules, because a variant has none of its own. Rules that name an option or value this product does not have are kept, counted in the message and listed under No longer on this product:. This is the way to put rules on a product that already exists, where OpenCart's Copy only makes a new one, and it is how a variant promoted by deleting its master gets rules back. The row is shown only to a user group that may store rules; see install.

The Configurator tab warns about rules that cannot work. When the product form opens, a warning above the rules lists three kinds of problem: a required option whose every value on this product is sold out; a rule that can never fire, because a condition names an option or value no longer on the product, names a sold-out value, or asks for two values of one dropdown or radio option at once; and a require that a hide on the same option always beats. The warnings never block a save and never change a rule, and they reflect the product as last saved: save and reopen the form to check again. See check a ruleset before customers do.

Nothing about your rules, your settings or your storefront changes on upgrade. Nothing is added to the storefront, no table changes and no setting is added.

1.4.0 — 21 September 2026

A customer editing a configured line and changing nothing no longer loses the line. On OpenCart 4.0.2.2 and 4.0.2.3 that is what happened: the shopper pressed Change options, left every answer as it was, added it back, and the line vanished from their basket. On those two releases OpenCart stopped refreshing its own copy of the cart after an add, so the check that asks did this re-add merge into the line being edited? was reading the quantity from before the add, concluding it had not merged, and removing the only row the line had. The quantity is now read from the cart table itself, which is right on every release. Nothing else changes, and nothing about how an edit behaves was meant to change: an edit that changes nothing has always been meant to leave one line at the quantity you posted, and now it does everywhere.

4.0.2.2 and 4.0.2.3 are now tested releases, which they could not be while that was true. So are 4.0.2.1, 4.1.0.1 and 4.1.0.2, which a full pass went through after 1.3.0 had shipped. The compatibility list runs 4.0.2.0 through 4.1.0.4 with one gap, 4.1.0.0, and limits says what OpenCart itself gets wrong there. The settings screen now says it too, on a store that is on it.

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 is 4.0.2.0, 4.1.0.3 and 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 Product Configurator nothing. A configuration is priced on the request that builds it and the option rules are written from the admin product form, so there was never anything here waiting on a schedule. Nothing else changes.

1.2.0 — 21 September 2026

Product Configurator now publishes what it holds about a person, and the answer is nothing. All twelve columns of its three tables are written down on what this holds about a person, every one of them classified as holding nothing about anybody, with the reason it is there. A configurator rule is a statement about a product's own options; nothing a visitor chooses is written down anywhere.

The page exists because the build keeps the claim true: a thirteenth column added to any of those tables has to be classified or make check fails naming it. A list that only named the personal columns could not tell a new personal column from a new counter.

• Customers > Personal Data is new, and answers what this and every other extension on your store holds about one named person, from one screen. Product Configurator's answer is zero, stated on the screen rather than left out.
• Remove everything held about a person is new and ships for the same reason. It is not on the Customers menu, and because nothing is held here the settings screen offers no link to it either; the day a column on one of these tables holds something, it starts emptying it.
• The settings screen gains a standing card saying what is held and that uninstalling keeps it.
• Nothing about your rules, your stored data or your storefront changes on upgrade.

1.1.0 — 11 September 2026

Nothing a shopper or a store owner can see changed in this release. Product Configurator gains the machinery for reading 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 ships English and only English today, so that question has one answer and every screen is what it was.

A store running more than one language gains one read-only card on the settings screen, saying which language each of yours is served from. The two sentences this extension says to a shopper stay ours to word. See Limits and guarantees for why neither is a box you fill in.

1.0.0 — 4 September 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: conditional options on top of OpenCart's own product options. A rule reads as a sentence (WHEN Frame material is Aluminium THEN hide the option Wood stain), and there are three verbs, show, hide and require, each aimed either at a whole option or at one single value of one. Conditions join with AND, as many as you like on one rule, written against any select, radio or checkbox option. Naming an option in a show rule is what makes it hidden until the configuration calls for it. A value-level rule is the compatibility case: pick a motherboard and the memory sizes it will not take disappear from the list, rather than the list disappearing.

The rules are written on a Configurator tab of OpenCart's own product form and saved by that form's own Save button, with no second screen and no second save, and a rule can name an option you added to the form a second ago and have not saved yet. Copying a product copies its rules, which is how ten products get the same configurator; deleting a product deletes them.

On the storefront the options appear and disappear as the customer clicks, with no reload, on the page your theme already renders, with no template edit and no theme change, and option values can draw as image swatches from the image OpenCart already holds on the value. A Change options link on the cart lets a customer fix one field of a long configuration instead of rebuilding it. The same rules are enforced on the server by OpenCart's own validation, with OpenCart's own messages, on the storefront, through its API and in the admin order editor, so a stale page or a hand-built form cannot buy a combination you do not sell.

Everything else about an option stays OpenCart's. The price a value adds, the stock it holds and the way the choice prints on the order page, the invoice and the order emails all keep working untouched, because every answer your customer gives is an ordinary OpenCart option answer. It arrives switched off, and switching it off again changes nothing anywhere while keeping every rule you wrote.

What it does not do is the shorter list. Read it first. There is no live preview, no reusable configurator template, no percentage pricing or rule that changes a price, and no stock of its own. Hiding is availability, not secrecy: every option and value attached to the product is in the page source whether a rule reveals it or not.

It runs on OpenCart 4.0.2.0 and 4.1.0.3, the two releases a full install-to-uninstall pass has been run against. Below 4.0.2.0 it refuses to install outright, with a message naming the version you need, rather than half-installing. Above 4.1.0.3 it installs and runs, and says on its own screen that the store is newer than anything a pass has been through. See requirements and install.

What an update keeps

Every rule you have written survives it. Removing Product Configurator deliberately leaves its three tables and everything in them alone, so reinstalling puts the extension back over the rules it left behind. An update is never a re-authoring job. Where your data lives and what a removal leaves is on the limits page.

What you built comes back; the settings below do not. An update is an uninstall and then an install, and OpenCart deletes an extension's settings at the uninstall step. Product Configurator keeps it in tables of its own and nothing here ever drops one — they hold your records rather than a copy of what you set, and Product Configurator keeps no copy of the settings themselves.

These are asked for again rather than put back:

• module_product_configurator_status — Being switched on is OpenCart's own record rather than ours, and Product Configurator keeps no copy of it. Setting Status back to Enabled is what turns the extension back on, on the screens it works through, so an update is not finished until you have.
• module_product_configurator_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 Product Configurator 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.