Settings

Product Configurator keeps its settings in OpenCart's own setting table, under the module_product_configurator group. You set them at Admin > Extensions > Extensions > Modules > Product Configurator.

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_configurator_status install-wide	0	Whether the module does anything at all. Off, nothing changes anywhere: no Configurator tab, no swatches, no hiding and no enforcement. Read once for the whole installation rather than per store, because what it governs is a set of rules hanging off one oc_product row, which every storefront shares.

Rules

ruleset — install-wide

One row per product that has rules, created the first time you write one on that product's Configurator tab. Nothing you ever name or see, and it holds nothing you set: it is the indirection that lets a later version share one set of rules between products without moving your data.

rule — install-wide

One row per rule: what it does, and what it is aimed at. Written on a product's Configurator tab. Rules are unordered — nothing about how a product resolves depends on which you wrote first — and where two rules disagree about the same target, hiding wins, which is the only direction that cannot build a product nobody can buy. The verbs and the targets are on the rule grammar page.

• action — What the rule does while its conditions hold: hide the target, show it — which is what makes it hidden the rest of the time — or require an answer to it. Starts at empty.
• target_type — Whether the rule is aimed at a whole option or at one value of one option. A value target is the compatibility case: the memory sizes a motherboard will not take disappear from the list rather than the list disappearing. Starts at empty.
• target_option_id — Which of the product's options the rule is aimed at. Filled for a value target too, so nothing has to query for the option a value belongs to. Starts at 0.
• target_option_value_id — Which value of that option the rule is aimed at, and zero on a rule aimed at the whole option. Starts at 0.

condition — install-wide

One row per WHEN line of a rule. A rule with two conditions has two rows, which is why there is no limit on how many conditions a rule may have. They are joined with AND and with nothing else: two rules with the same target are already an or, so write two rules where you mean one.

• option_id — Which of the product's options the condition reads. Only options whose answers are values you set in advance can hold one — a dropdown, a radio group or a checkbox group — because a condition on a typed answer would be matching whatever the customer typed. Starts at 0.
• option_value_id — Which value of that option the condition is looking for. On a checkbox group is means is among the values ticked. Starts at 0.

Advanced

Key	Default	What it does
module_product_configurator_diary_verbose_until install-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.

Rules

A set of rules belongs to one product. There is no store-wide set, no category-wide set and no way to share one set between two products, so a merchant with four hundred configurable products writes four hundred sets. That is published rather than hidden, because it is the thing to know before buying: the tables already carry the indirection a shared set needs — a second product pointing at the same set is an admin screen rather than a migration — and it is a later version's job, not a setting you are missing.