Settings¶
Product Search keeps its settings in OpenCart's own setting table, under the
module_product_search group. You set them at
Admin > Extensions > Extensions > Modules > Product Search.
Each key below carries where it applies. per store means a multi-store install can hold a different answer per storefront, and both are honoured: a read takes what that store holds, then what the default store holds, then the shipped default. install-wide means one thing serves every storefront, and the key's own description names that one thing.
Scope¶
| Key | Default | What it does |
|---|---|---|
module_product_search_statusper store |
0 |
Whether searching is this extension's job. Off leaves the storefront exactly as OpenCart ships it. Per store, so a multi-store install can run this search on one storefront and core's on another. |
module_product_search_api_enabledinstall-wide |
0 |
Whether the extension answers API requests at all. Off, every API route answers 404 api_disabled in the API's own JSON envelope, so an extension with its API off is shaped like one that has none. Read once for the whole installation from the default store rather than per store, because the one thing it serves is OpenCart's own API user, which has no store of its own. It is a separate switch from the extension's own Status, and the two are read independently: the API answers whether or not this search is switched on, because what shoppers searched for is the merchant's own record and a storefront switch should not hide it. The API only ever reads the search counters; synonyms and merchandising rules are not readable through it. |
Reports¶
| Key | Default | What it does |
|---|---|---|
module_product_search_log_statusper store |
1 |
Whether each search is counted into the daily totals the search report reads. The counters hold no IP address, no customer and no session identifier — only a keyword, a day and two numbers. Per store: the counters carry the storefront they were typed on, so one shop may be measured while another is not. |
module_product_search_retentioninstall-wide |
365 |
How many days of search counters are kept. Older days are thrown away when the search report is opened, and 0 keeps everything and means it. Read once for the whole installation rather than per store, because the one thing it serves is that single delete: it runs against one counter table with one cut-off date, and two stores asking for two windows would be two answers to one question. |
module_product_search_report_daysinstall-wide |
30 |
How many days the search report opens on before you pick your own dates, counted inclusively with today. A seasonal shop comparing against last quarter re-picks the range on every visit at the shipped answer. Between 1 and 3650. Read once for the whole installation rather than per store, because the one thing it serves is the report screen, which one administrator opens and which carries its own store filter. |
Indexing¶
| Key | Default | What it does |
|---|---|---|
module_product_search_typo_statusper store |
1 |
Whether a search that finds nothing is run again with the shopper's spelling corrected against what this catalogue actually says. Set per language on the settings screen, and stored as one answer per language: a shop whose German names are mostly part numbers wants this off there and on in English. A language with no answer saved is on, because a language added since the last save has not been switched off — it has not been asked about. |
Merchandising¶
| Key | Default | What it does |
|---|---|---|
module_product_search_pin_maximuminstall-wide |
10 |
The most products one merchandising rule may pin to the top of its results. It deliberately cannot be worked out from your page size, which you are free to change under it: a store showing 40 products a page can merchandise a quarter of page one at the shipped answer. Between 1 and 100; a number outside that is saved as the nearest one inside it. Read once for the whole installation rather than per store, because the one thing it serves is the merchandising table, which has no storefront column — a rule is a fact about a keyword in one language. |
merchandising — install-wide
One row per merchandising rule: a keyword, and the products you want at the top of its results in the order you want them. Written on the Merchandising tab. The pinned products lead the page and everything else follows in the order the search found it, at every page size — so a rule means the same thing whatever a shopper has their pagination set to. Install-wide for the same reason a synonym group is: the table is keyed on a language and a keyword and has no storefront column.
language_id— Which language the keyword is typed in. Starts at0.keyword— What a shopper types. Normalised the same way a search is, so a rule written forRunning Shoesfires onrunning shoes. Empty is the zero-result rule, When a search finds nothing, at most one per language: its products are shown when a search finds nothing at all, even after typo correction. Starts at empty.products— The products to lead with, in the order they lead. How many you may name ismodule_product_search_pin_maximumabove. Starts at empty.status— Whether the rule is live. Off leaves it on the screen and out of every search. Starts at1.
Synonyms¶
synonym — install-wide
One row per synonym group: a set of words a shopper may use for the same thing, any of which finds the products described by any other. Written on the Synonyms tab, which also exports one language's groups as a CSV file and imports one back: an import replaces all of that language's groups or, if any line is refused, none. Install-wide because a group is a fact about one language's vocabulary and the table has no storefront column — two shops in the same language want the same answer, and one that does not is asking for a different catalogue rather than a different synonym.
language_id— Which language the group applies to. Groups never cross languages:pantsmeans two different things in two of them. Starts at0.terms— The words in the group, one per line so that a term may be a phrase — a comma would splitvacuum cleaner, uprightin two and nobody would find out. They are normalised as they are saved, so what the form counts is what the storefront expands. Starts at empty.status— Whether the group is live. Off leaves it on the screen and out of every search, which is what makes a group something you can try rather than something you delete. Starts at1.
Advanced¶
| Key | Default | What it does |
|---|---|---|
module_product_search_diary_verbose_untilinstall-wide |
0 |
When detailed logging stops, as a unix timestamp, and 0 is off. Turning Detailed logging on from this extension's settings form stores the moment two days from now; the writer compares that against the clock every time it is asked for a DEBUG line, so the window closes on its own with no scheduled task and nothing to clean up. While it is open this extension records what it did in far more detail, and the shared diary consequently holds less history. |
What you cannot change, and why¶
These are fixed on purpose. Each one is a decision with a reason beside it rather than a setting nobody got round to adding.
Indexing¶
How much misspelling is tolerated is fixed. Every number behind it is one a merchant has no basis to choose — how long a word has to be before it is corrected at all, how many corrections one query may try, how much of the catalogue a correction reads to find them — and every support conversation about a configurable one begins with what did you set it to. The one thing that is configurable is whether any of it runs, which is the per-language switch above.
| Rule | Value |
|---|---|
| Shortest word corrected at all, in characters | 4 |
| Word length above which two edits are allowed | 8 |
| Words of one query that may be corrected | 5 |
| Alternatives tried per word | 5 |
| Leading characters a correction must keep | 2 |
| Products a correction reads names from | 500 |
| Names it keeps to correct against | 1000 |
| Leading characters it narrows the catalogue on | 2 |
Synonyms¶
How few and how many terms one synonym group may hold is fixed. One term is not a group — it expands to itself and changes no search, and left accepted it would be a row you had written, saved and could see on the screen, doing nothing. The ceiling applies to a paste and an imported file alike: what a search costs grows with the total number of alternatives a word carries, and a group of two hundred terms is a query no storefront wants to run. Neither is a judgement about your catalogue, which is why neither is yours to make.
| Rule | Value |
|---|---|
| Fewest terms a group may hold | 2 |
| Most terms a group may hold | 20 |
Reports¶
The search counters hold a keyword, a day, a store, a language and two numbers, and there is no setting that adds anything else — no IP address, no customer, no session identifier, now or by a column added later. OpenCart's own search log holds all three, which is why core ships it switched off and why a merchant who left it that way may have done so on legal advice. There is nothing here to leak and no setting to get wrong.
A search the zero-result rule answered is still counted as a search that found nothing, and there is no setting that counts it otherwise. The report's zero-result searches are the queue of terms your store has no answer to, and the rule's products are what it shows instead of an answer. Counted any other way, that queue would empty the day the rule is set and stay empty whatever shoppers typed. A merchandising rule for the search itself still takes it off the queue, because that is you answering it.