Settings
Settings written down, including the ones we refuse
Every extension we sell publishes every setting it has: what each one does, where it applies, and what it starts at. Beside them is what that extension fixes on purpose, and why. Neither half is typed by hand. Both are written out of the extension’s own source, and the build fails when either falls out of step with what ships.
What is on an extension’s settings page
A row per key: its name as it appears in the database, what it does in a sentence written for somebody deciding whether to change it, what it starts at before anyone touches it, and where the answer applies. The keys are grouped the way that extension’s own screen is grouped, so the page and the screen read in the same order.
It is a page to read before you buy rather than after. It answers the question "can this thing be made to do what my store needs?", which you would otherwise answer by installing it and looking, or by asking and being told yes.
Where a setting applies
Per store. 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. That is what OpenCart does with its own settings.
Install-wide. One thing serves every storefront (one index, one cron tick, one credential, one host, one file on disk), and the key’s own description names the thing it serves, so you do not have to take it on trust.
On a row rather than on a screen. Some answers sit on the thing they are about: a product, an option value, a language, a customer group, an import job. Where an extension carries those, its page says what they are keyed on and which of them wins where two of them meet.
Where each extension’s settings apply, extension by extension
What our extensions will not let you change
Every extension names at least one thing it fixes on purpose and says why: a window whose wrong value orphans a lock, a length of secret a merchant could shorten, an anchor a theme has to keep, a level of the catalogue the design refuses to spread a rule across. They sit at the foot of the same page as the settings, in the words below, because a missing setting is cheaper to find before you buy than after.
"Every setting here is install-wide and there is no store selector, which is this extension alone among the ones sold here. The reason is OpenCart’s own stock column: it keeps one oc_product.quantity for every store, so units shared between two storefronts have to be rationed between them too, and the minimum-quantity gate appears in the predicate at both levels — a per-store gate would mean the same option value was available and unavailable at once on a pair of stores sharing the column." — Back In Stock, on its own settings page
"The numbers that decide when a plan is worth warning about belong to a job and have no store-wide default, deliberately. What is alarming depends on the feed: a wholesaler’s quarterly price list moves every price by 40% and a daily stock file moves none of them, so a number that was right for one would teach an operator to click past the other." — Import/export, on its own settings page
"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." — Product Search, on its own settings page
Those are quoted as they are written in the source they are checked against. The rest are on the settings page of the extension doing the refusing, which is linked from every row of the promise.
How this is kept true
Both halves of a settings page are written out of a declaration in the extension’s own source. It is the same declaration its admin form and its upgrade note are built from, so there is no second list to keep in step. Our build regenerates the page and fails when the committed copy differs, which puts a stale page in front of the person who made it stale rather than in front of you.
The same pass refuses an extension that writes a setting it never declared, one that declares a setting with no description or nothing to start at, one that claims a per-store answer on a screen that cannot save one, and one that says a setting survives an update when nothing puts it back.
It is not something an extension opts into. An extension is held to this by being an extension we ship rather than by having been added to a list of participating ones, and deleting its declaration fails the build instead of ending the obligation. That is what makes the section above worth reading: a refusal nobody is forced to keep is a weakness somebody wrote down, and this one is kept by the same run that ships the code.