Changelog

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

1.7.1 — 3 October 2026

A merchandising rule now keeps every product you pin. The settings let one rule pin up to 100 products, but the list was stored in a column that held about fifty, and a longer one was cut short on save while the screen still said it had saved. The later pins were lost, and a product id cut in half could pin a different product. The column now holds a hundred, and the update widens it on your store. A rule saved with more than about fifty pins before this release should be opened and checked, because what was cut off then is not coming back.

A save that leaves out the synonym groups leaves them alone. Saving the settings used to rewrite the synonym groups every time, so a save that did not carry them, from a script or a form built by hand rather than the settings screen, deleted every group the store had. The screen itself was never affected, and removing every row there still clears them.

A second store no longer freezes the default store's install-wide settings on update. A storefront saved on its own tab came back from each update with its own copy of Keep Search Totals For, Most products one rule may pin and Report opens on, so changing them on the default store stopped reaching it. They are now read from the default store again, as which settings are per store says.

Detailed logging now records something. The switch was saved and timed correctly but nothing extra was written while it was on. It now writes a line for each search page, giving the store, language, category and how many products came back, and never the words the shopper typed. With the switch off it costs a search page nothing. An update also put an open window back on before; it now comes back off, as what an update keeps says.

Smaller corrections. Clear now says how many days it cleared rather than how many counter rows. Pinned product names and report keywords are escaped on the settings screen, so a name an import wrote with markup in it shows as text.

Nothing to do on update. No setting is added or changed, and the API is unchanged. The update widens one column on the merchandising table.

1.7.0 — 2 October 2026

A read-only JSON API, off until you switch it on. Another system can read the same daily totals the search report shows: one row per keyword, store, language, category and day, with how many searches it had and how many found nothing. Nothing about who searched is in it, because nothing about who searched is stored, and your synonym groups and merchandising rules are not readable through it. Switch it on under API on the default store'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 index to the search counters table, which is what lets the API page through it without reading it whole.

1.6.0 — 30 September 2026

You can choose what a search that finds nothing shows. The first row of the Merchandising list, When a search finds nothing, is a rule with no keyword: its products answer a search that matched nothing at all, in your order. It stands down when the shopper sorts or filters, and the search is still counted as returning nothing in the report. See limits and the guide.

The search report downloads as a CSV: every keyword the filter matches, not only the page on screen. See the guide.

Synonym groups move in and out as a CSV file, one language at a time. An import replaces that language's groups, all of them or, if any line is refused, none. See the guide.

1.5.0 — 26 September 2026

Adds the hook Advanced Product Filters uses to put facets on search results. Nothing changes unless you install it.

The search listeners now run ahead of B2B Pricing's price rewrite, so a buyer on a price list sees their list prices in search results.

1.4.0 — 21 September 2026

The settings screen now says what OpenCart 4.1.0.0 has taken away. On that release OpenCart builds its price sort as invalid SQL, so a shopper who picks Price from the Sort By box gets a database error instead of a page. This happens on every listing OpenCart offers that sort on, not only search. Every other sort works, and so does the search itself, the synonyms, the corrections, the pins and the statistics. No extension can repair this, and 4.1.0.0 is not claimed. See limits.

4.0.2.1, 4.0.2.2, 4.0.2.3, 4.1.0.1 and 4.1.0.2 are now written down as tested releases, which they already were. The list now runs 4.0.2.0 through 4.1.0.4 with 4.1.0.0 as the one gap, rather than naming three of them and leaving the rest to be inferred.

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 Product Search nothing. The rewrite happens inside the shopper's own search request, and synonym groups and merchandising rules are edited from your own screen, so there was never anything here waiting on a schedule. Nothing else changes.

1.2.0 — 21 September 2026

Product Search now publishes what it holds about a person, and the answer is nothing. The page also lists the three columns it deliberately does not have, and why. All twenty-five columns of its four tables are on what this holds about a person, every one classified as holding nothing about anybody.

The daily search statistics hold no IP address, no customer id and no session identifier, now or by a column added later. OpenCart's own oc_customer_search holds all three, which is why core ships that feature switched off. If you found it switched off and left it that way, you may have been told to. Because there is no identifier on the table and none reachable from it, there is nobody for an access, export or erasure request about your search data to be about: the row is a counter over a (store, language, category, keyword, date) bucket, shared by everybody who typed that phrase that day.

That was true before this release, in a comment beside the schema where you would never have read it. What is new is that it is on a page, and that our build keeps it true: an ip column added tomorrow has to be classified or the build fails naming it.

• 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 Search's answer is zero.
• Remove everything held about a person, linked from the settings screen, is new and ships for the same reason. It opens on an empty plan here, and 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 synonyms, your merchandising rules, your statistics or your settings changes on upgrade.

The settings screen now saves per store. A Store picker at the top of the screen chooses which storefront the Settings tab is for, and Status, Count Searches and Forgive Misspellings are kept per store: one storefront can run this search while another keeps OpenCart's. Before, every save landed on the default store. A store you have never saved still runs under the default store's answers, so nothing changes until you pick a store and save it. See which settings are per store.

Two limits that were fixed are now settings, on the default store's form: Most products one rule may pin (10, as before) and Report opens on (30 days, as before). Leaving them alone keeps the behaviour you had.

Detailed logging, and a log you can download. Product Search now writes what it did and what it refused to do to the shared Kyvero log, and a Detailed logging switch on the settings screen records more for two days and then switches itself off. See what Kyvero extensions log.

Product codes are now found wherever your store keeps them, which on some OpenCart 4.1 stores is two places at once. OpenCart moved SKU, UPC, EAN, JAN, ISBN and MPN out of the product row and into a table of their own in 4.1.0.1, and finished the move in 4.1.0.4. A store upgraded into the range between them has both: the old columns hold whatever was there on upgrade day, and OpenCart no longer reads them. A product nobody has re-saved since can have a SKU that its own search box cannot find. Product Search now asks your database which of the two it has and searches both where both are there, so upgrading OpenCart does not silently cost you a code.

On OpenCart 4.1.0.0 specifically, this is the difference between a search page and an error page: that release has none of the newer table, and Product Search was asking for it anyway. 4.1.0.0 is still not a release this extension claims, because its own search breaks on a Price sort before Product Search is reached. That is core's bug, and no extension can work around it, but nothing this extension does adds to it any more.

1.1.0 — 10 September 2026

On a store with one language nothing you can see changed. Product Search still ships English and only English, so every screen reads exactly as it did in 1.0.0. There is no new setting, no language to pick and no row on the form.

What it gains is the machinery for reading a translation of its screens once one exists: the extension now works out which of the languages it ships your admin should be served, rather than assuming your language code is spelled the way our directories are. With one language shipped that question has one answer, so a store running in one language is not asked anything and pays nothing.

On a store with more than one language, the Settings tab now says so. A new read-only Language section lists every language your store has, including any that are switched off, and, for each, which of Product Search's own translations it is served from. Today that is English for every language but English, and the section says which: not translated. Read it as a statement about these settings screens, not about your shopfront. Product Search says nothing to a shopper: it reorders the results on OpenCart's own search page, and OpenCart renders that page in the shopper's own language. There is nothing to set here and nothing to save.

There is still nothing here a shopper reads, and there never will be. See Limits and guarantees for what that means for the translation figures published for this extension.

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: a storefront search where every word a shopper types has to match something; brand names and category names counted as things to match against, so a shopper who types your manufacturer's name or a department gets the products; synonym groups you author per language, so the word your customers use finds the word your catalogue uses; typo tolerance that corrects a search returning nothing against your own catalogue and retries it silently, and never corrects a product code; merchandising rules that put the products you choose in front of a given search, in your order, whether or not they would have matched it; and a search report of what was typed, how often, and how often it came back with nothing (daily totals per store and language, holding no IP address, no customer and no session), where each row is one press from the synonym group or the rule that answers it. No storefront markup, no JavaScript, no template edits, and no scheduled task to set up anywhere. What it does not do is the shorter list; read it first.

One thing on that list is a change to behaviour you already have, and it is the reason to read limits and guarantees before switching it on: on OpenCart 4.1.x your results get narrower. Core requires either word of a two-word search there; Product Search requires both, at every release. On 4.0.2.0 nothing narrows, because core already required every word.

Product Search is off until you switch it on, on its own settings tab. Installing it changes nothing your shoppers see. Turning the module off, or uninstalling it, hands the very next search back to core.

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 synonym groups, your merchandising rules and your search counters live in tables nothing 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. Product Search 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_product_search_status, module_product_search_log_status and module_product_search_typo_status, which each store keeps its own of.

These are asked for again rather than put back:

• module_product_search_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 Search 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.