Preparing a Commercial Module for PrestaShop 9.2 Compatibility

A commercial module’s compatibility claim is a promise to a merchant about a combination of software and behavior. “Installs on PrestaShop 9.2” is a much smaller claim than “supports the native checkout, migrated administrative pages and multistore operation.”

For the 9.2 RC1 available on September 26, 2026, publishers should describe candidate testing precisely. A passing RC evaluation does not justify calling the unreleased stable version supported. This article explains how to qualify an existing module product, not how to build its skeleton.

If the module participates in payment or delivery, include the One Page Checkout QA plan in the compatibility matrix instead of testing installation alone.

Define the support claim before designing the matrix

Write down the capabilities the module actually offers and the combinations customers are expected to use. A payment module has different critical paths from a catalog enrichment module. A Back Office-only extension may not need a full storefront theme matrix, while a checkout extension certainly does.

Separate mandatory support from optional compatibility. If the module supports only a particular checkout path today, state that explicitly. If multistore is unsupported, do not let installation in a multistore shop imply otherwise.

List the exact dependencies behind the claim: core, runtime, native modules, theme where relevant and external service integration version. Keep experimental dependencies visible rather than folding them into a broad version range.

A useful claim for the current milestone is “tested against 9.2.0-rc.1 with these named combinations and limitations.” It tells early testers what evidence exists without implying production readiness for the candidate.

Build the matrix around risk, not every possible permutation

Start with the module’s business effects. Which operation can change money, stock, customer data or shop scope? Which extension points have changed in the candidate? Which external dependencies can produce delayed or duplicate results?

Use a matrix that connects each risk to evidence:

Then select representative combinations. Test the lowest and highest runtime versions you claim to support, with the dependency combinations most likely to expose differences. Add targeted cases where code branches on platform version.

Do not claim that a pairwise matrix proves every combination. It is a coverage strategy whose limitations should remain documented.

Treat checkout and migrated pages as separate integration surfaces

For a checkout module, verify both the supported buying flow and its dependent payment or carrier interactions. Test refresh, changed address, failed submission and repeated initialization. A module that only reacts to the initial page load may behave differently in the native one-page flow.

For Hummingbird or a child theme, record the theme revision and relevant overrides. The checkout’s template and DOM contract is a concrete integration dependency, not merely a styling preference. Official checkout theme contract.

For administrative extensions, identify migrated pages and active flags. Test the intended form save, grid filter and employee permission boundary on each supported path. Do not use a SuperAdmin-only smoke test as evidence for ordinary staff workflows.

Verify that compatibility code does not execute twice when both old and new hooks are registered. The absence of a fatal error is not enough if one action produces duplicate writes or notifications.

A publisher should be able to connect every compatibility adjustment to a failing case or a documented contract change. Avoid broad rewrites whose benefit cannot be demonstrated.

Review runtime assumptions and version-specific services

Runtime compatibility includes code that executes only during unusual lifecycle stages: installation, uninstallation, scheduled jobs, error handling and provider callbacks. Exercise those paths under the runtime versions included in your declared support range.

The 9.2 work adds support for PHP service definitions and version-specific YAML service files. This creates a way to adapt service wiring while preserving older-version support, but the selected loading behavior must be verified in the matching implementation. Version-specific service configuration change.

If you adopt that mechanism, test the service container on every platform branch you claim. Confirm which file is selected and that no service exists only because a developer’s local cache retained an old definition. Do not assume several alternative service files will all be merged.

For PHP 8.5 claims, lint and execute the relevant tests on PHP 8.5 itself. Core compatibility does not automatically validate a module’s dependencies. The RC release notes list PHP 8.5-related fixes, which reinforce the need for version-specific testing rather than a blanket inference. Candidate release changelog.

Also inspect finite-value assumptions. The 9.2 product-condition change adds values that a module with a hard-coded allowlist may reject or mislabel. If your module reads conditions, compare its supported values with the actual candidate enum and define behavior for an unfamiliar value. Product-condition change.

Test customer-data continuity across lifecycle operations

Install the released module version into a disposable baseline, create representative data, then apply the candidate module update through the supported mechanism. Verify that existing values remain meaningful and that new defaults do not overwrite deliberate settings.

Repeat the update attempt where the lifecycle permits it. A partially completed update should not create duplicate definitions, indexes or business records. Record how the module detects and recovers from an interrupted step.

Test disable and re-enable separately from uninstall. Merchants often disable a module while diagnosing another issue; that action should follow the documented retention policy. If uninstall can remove data, make the policy explicit and verify it with synthetic records.

For Extra Properties or custom tables, include shop and language variations. A migration that preserves only the default shop can appear successful in a simple fixture while losing the information that matters to a multistore customer.

Do not use destructive cleanup merely to make the package reinstall cleanly during development. Commercial lifecycle behavior needs to reflect customer expectations and the module’s published policy.

Validate the distributable artifact

Run the acceptance suite against the archive customers will download. A development checkout may contain generated assets, vendor dependencies or configuration files that are absent from the packaged module.

Inspect the archive’s structure and required files. Confirm that it installs through the supported Back Office or deployment workflow and that its assets load without relying on development tooling. Keep tests and build artifacts only where the distribution process intentionally requires them.

Check that no credentials, local environment files or production extracts are included. This is a concrete packaging check, not a reason to add irrelevant compliance material to the product’s user interface.

Record the artifact checksum or build identifier with the test results. If a package is rebuilt after qualification, determine whether the content changed and rerun affected checks. A version label alone cannot distinguish two different archives carrying the same number.

Give a support limitation an executable boundary

A limitation should identify the excluded behavior, not merely say that some features are unsupported. If an extension supports the legacy administrative path but not the migrated one, record the affected page and the test that demonstrates the gap. If a payment integration excludes a particular one-page interaction, name that interaction and the supported alternative.

Avoid presenting a flag workaround as a permanent guarantee. It may be useful during candidate evaluation, but a future release can retire the old path. Assign an owner to the adaptation and track the condition that will remove the limitation.

For external dependencies, retain the vendor’s version-specific statement with your own results. If the vendor later withdraws support or changes a contract, the evidence record makes it clear which customer combinations need review.

This also improves support triage. An incident inside the declared matrix is a potential regression. An incident outside it is still worth investigating, but it should not be confused with a previously qualified combination.

Write the distinction in language merchants can use: the operation, the versions and the practical effect. Internal test-suite names are useful to engineers but should not be the only explanation a customer receives.

Publish limitations that help merchants decide

Release notes should say what behavior is newly supported, which combinations were exercised and what remains excluded. “Various compatibility improvements” tells a merchant little about whether their checkout or multistore workflow is covered.

Provide a short reproduction template for early testers: core, module and theme versions, active flags, shop context and action sequence. This reduces support exchanges spent reconstructing the environment.

When stable 9.2 is officially released, compare its final changes with the qualified candidate and rerun the affected matrix before broadening the support statement. A candidate pass is valuable preparation, but it is still tied to the candidate artifact.

A strong compatibility claim is therefore an evidence package: a bounded support contract, targeted regression cases, a verified distributable archive and honest limitations. That helps merchants make a deployment decision and gives the publisher a manageable support boundary.

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.

When selecting an extension, browse PrestaSuite’s PrestaShop 9 modules and check the documented version support and integration requirements against your own test results.