PrestaShop 9.2 Multistore: Configuration and Property Scope

Multistore testing fails when every shop looks the same. If two shops share identical settings and fixture values, an accidental write to the wrong scope can pass unnoticed. The new 9.2 multistore work is best evaluated with deliberately different shop behavior.

This article focuses on release-specific changes in configuration forms, Extra Properties availability and tax-rule listing. It does not teach general multistore module architecture. The examples are proposed RC1 checks for September 26, 2026, and belong in a disposable test installation.

For module-owned data beyond these release changes, apply explicit multistore data scoping to reads, writes, scheduled work and caches.

Administration and Product Settings gain explicit multistore handling

The merged 9.2 change for Administration and Product Settings adds multistore form integration and scope-aware configuration handling. Its upstream test instructions call for single-shop edits and checking that changes stay in the selected shop. Configuration-form change #41409.

The merchant-facing significance is clearer control over whether a setting belongs to a selected shop or is inherited. The operational significance is that staff must understand the context in which they save.

Begin with two shops in a known group structure. Choose a harmless setting that the page exposes as multistore-aware and document the inherited value before changing anything. Do not assume every field on a multistore page has the same scope semantics.

Use the actual checkboxes and inheritance controls displayed by the candidate. Avoid changing configuration rows manually to simulate the feature, because that bypasses the very form behavior under evaluation.

A successful save notification is only the first observation. Reopen the page in each shop and inspect the downstream behavior affected by the setting. The value should remain correct after a fresh request.

Run an inheritance experiment with a visible difference

Suppose the selected setting is inherited from the parent context. Record that baseline in both shops. In shop A, create an explicit override through the form. Leave shop B inherited.

Now change the parent value through the supported interface. Shop B should follow the applicable inheritance rules, while shop A should retain its explicit override where that is the documented behavior. Finally, remove A’s override through the interface and verify the value it inherits.

This sequence distinguishes an inherited value from an explicit value that merely happens to be equal. Those states can look identical today but behave differently after a parent change.

The general PrestaShop multistore form documentation describes controls for selecting local configuration versus inheritance and helper methods that apply scope-aware updates. Use it to interpret the UI, while the 9.2 PR establishes which pages gained the handling. Multistore configuration forms.

Record the experiment in a small table:

If a field does not support a particular context, record that limitation rather than trying to force the table’s idealized behavior onto it.

Check disabled controls and their downstream meaning

The same configuration PR addresses a Product Settings case involving out-of-stock ordering behavior when stock management is disabled. It is a reminder that a disabled control still participates in a configuration workflow and must not accidentally become an invalid missing value. Product Settings handling.

For a store-specific test, capture the starting stock-management configuration and the expected product behavior. Change the controlling setting in a test shop, save and reopen. Confirm that the dependent field’s effective value and the storefront behavior agree.

Repeat in the second shop with a different configuration where supported. This can expose a form that displays one shop’s state but persists another’s fallback.

Avoid drawing conclusions from the appearance of a disabled input alone. The business question is whether the resulting configuration is valid and applies to the intended shop. Browser controls can be disabled while the server still needs to derive an explicit value.

If your module reacts to the save operation, verify that its business effect occurs once and in the correct context. Do not assume a core form improvement automatically fixes custom code that reads an ambient default shop.

Extra Properties adds a second kind of shop decision

A shop-specific value and a shop-restricted definition are different things. The first answers “what value does this shop use?” The second answers “is this field available in this shop at all?”

The 9.2 RC work includes restricting Extra Property definitions to a list of shops. Use that change to evaluate fields relevant to only part of a multistore installation. Definition restrictions #42490.

Imagine a wholesale shop that needs an internal catalog-review field while a retail shop does not. First verify where the field is presented and accepted. Then verify its value behavior within the allowed scope. A hidden field in the retail form does not, by itself, prove that every other reader respects the intended availability.

Check form, grid and enabled API surfaces independently. Include a product shared between shops and a product associated with only one. These fixtures distinguish definition restrictions from entity association and value scope.

Do not assume that restricting a definition deletes old values or performs a data migration. If a field’s allowed shop list changes, inspect the documented lifecycle and test what remains in a disposable environment. Availability and retention are separate decisions.

Tax-rule grids need association-aware regression checks

The RC1 changelog includes a fix for duplicate tax-rule-group grid entries in multistore context. That is a narrow listing correction, not a claim that tax calculation rules have been redesigned. Tax-rule grid fix #42245.

To evaluate the listing, create or use a synthetic group associated with the relevant shops. Compare the identifiers and row counts in single-shop and broader contexts. Apply a filter and move between pages if the fixture is large enough to exercise pagination.

The assertion is that the grid represents the intended logical records without association-driven duplicates. Do not change real tax configuration to produce a test case. Keep the fixture isolated and restore it afterward.

If an extension adds joins or columns to that grid, compare behavior with and without the extension. A core fix does not guarantee that a custom join cannot reintroduce duplication.

Keep listing evidence separate from tax-calculation evidence. One can be correct while the other is wrong, and they should not share a vague “taxes passed” status.

Make shop context visible in staff workflows

A technically correct multistore form can still be used incorrectly if staff overlook the selected context. Review the workflow with the employees who maintain settings, not only with developers.

Ask a tester to make a local change, explain which shops should be affected and then verify both the target and a non-target shop. If the tester cannot predict the scope, improve the operating instructions before relying on the interface in routine work.

For support tickets, include the selected shop or group and whether the field was inherited. Without those details, an apparent failure to save can actually be a misunderstanding of effective configuration.

Consider concurrent administration as well. Two employees changing parent and local values can create a surprising result even when each save is valid. Use the available audit or change records in your deployment to reconstruct the sequence; do not assume an old open form still reflects current inherited state.

Separate local overrides from copied settings

When preparing fixtures, do not create shop B by blindly copying every effective value from shop A into local configuration. That can remove the inheritance state the test is intended to exercise. Establish the parent value, then create only the local overrides required by the scenario through the supported form.

A useful staff exercise is to predict the effect of a parent change before applying it. Ask which shops should change and which should retain a local value. Compare the prediction with the reopened forms and the downstream behavior.

If the result differs, first inspect the stored override state and selected context. A value that appears unchanged may be an intentional local override rather than a failed save. Conversely, a changed non-target shop may indicate an overly broad write and deserves immediate investigation.

Keep this evidence alongside the version-specific cases. It explains whether the new form behavior is functioning correctly and whether the operating procedure makes its scope clear to staff. Both are necessary for dependable day-to-day administration.

For a shared staging environment, announce context-changing experiments in the team’s normal coordination process so another tester does not save an old form against a changed parent state.

Define acceptance by isolation and effective values

A good 9.2 multistore acceptance record names the affected page, field, selected context, inheritance state and resulting effective value. For Extra Properties, add definition availability and entity association. For grids, retain expected identifiers and counts.

The critical negative assertion is that a non-target shop remains unchanged. This should be observed, not inferred from the current shop’s success message.

These changes make specific parts of 9.2 worth reviewing for multistore operators. Test them with distinct values and explicit context, and keep general custom-module data ownership as a separate engineering concern.

For the underlying platform context, see our PrestaShop 9 module development guide and apply the version-specific checks above to the installation you are evaluating.