PrestaShop 9.2: What’s New in the RC1 Release

PrestaShop 9.2 gives merchants and developers several new areas to evaluate: a native single-page buying flow, a common system for additional entity fields, and an AI assistant inside the administration interface. The useful question is which of these changes affects work your store actually performs.

As checked on September 26, 2026, the available milestone is 9.2.0-rc.1, released September 21. It remains a pre-release for isolated testing. A release candidate is not a recommendation to replace a working production installation. Official RC1 announcement.

This article maps the 9.2 additions to business decisions. For the underlying platform changes, start with our PrestaShop 9 overview. The practical examples below are proposed evaluation exercises rather than reported results.

To examine the buying flow in more detail, review how native One Page Checkout changes buying before choosing your checkout acceptance cases.

Read the release at three different levels

A release number alone does not describe everything installed in a store. Distinguish the core version, bundled modules and enabled capabilities. A merchant testing a distribution package may encounter services that are absent from a custom core build. Another tester may have the same core but a different checkout-module revision or a different selection of experimental switches.

Record those differences before comparing screenshots or reporting a problem. A useful evaluation note identifies the archive, core version, theme version, relevant module versions and enabled feature flags. This prevents a discussion about “9.2 behavior” from mixing several different installations.

Also distinguish release maturity from feature maturity. A page can have its own maturity designation while the package containing it is still a release candidate. Conversely, a future stable core release would not automatically make every optional experiment ready for a production dependency.

For an agency, the result should be a small map of affected work: customer checkout, catalog enrichment, administrative assistance, Back Office extensions and integrations. Assign an owner to each area. That is more useful than asking one developer to “test the new version” without defining what success means.

The checkout addition changes an important integration boundary

The new native One Page Checkout brings the buying process into one page. Its significance extends beyond layout: the project offers a common implementation for payment, carrier and theme developers to support. The official introduction presents it as an optional checkout direction, not evidence that every store will convert better. One Page Checkout introduction.

For a merchant, evaluate what happens when a customer changes information after other choices have been made. An address change can affect delivery methods, taxes and the final amount. A carrier change can affect a pickup selector. A payment choice can introduce a redirect or an embedded form. Bringing those interactions together makes their coordination particularly visible.

Consider a shop selling both small accessories and oversized items. A convincing demonstration is not merely buying the accessory with the default carrier. Add the oversized item after choosing delivery, then verify that the carrier choice and displayed charge are recalculated consistently. The final order should reflect the latest cart, not an earlier screen state.

A store already using a third-party checkout should inventory its additional business rules before planning a replacement. Delivery-date selection, company fields and pickup preferences may belong to the current module or its extensions. The presence of a native alternative does not establish equivalent coverage.

Turn these concerns into acceptance cases before committing to a checkout replacement. Keep a record of the payment, carrier and theme combinations exercised, including any rule provided by a separate extension.

Extra Properties creates a shared home for additional fields

The 9.2 feature-freeze announcement identifies Extra Properties as a native entity-extension system with shop and language support and connections to administrative forms, grids and the API. 9.2 feature-freeze announcement.

The architectural opportunity is consistency. If a merchant needs a product-specific handling note, an agency can evaluate a shared extension mechanism before inventing another private persistence convention. That can make ownership and integration clearer, but only if the field itself is modeled correctly.

For example, distinguish a handling instruction from a warehouse-event history. The first is a value attached to an entity. The second is a sequence of events with timestamps, actors and relationships. A convenient custom-field mechanism should not become a container for every record that happens to mention a product.

There is a similar distinction between translated wording and different commercial values. A French translation of an instruction and a shop-specific instruction are separate dimensions. Decide which dimension actually varies before registering a field; correcting an ambiguous model after data entry is more expensive than choosing deliberately at the start.

For RC evaluation, begin with one reversible field and a small set of fixtures. Follow its value through entry, reload and the intended consumer. Do not migrate a production module’s entire data store merely to explore the feature. Developers implementing the experiment can use our PrestaShop 9 module development guide as a foundation for module structure and production preparation.

Ask AI and distribution integrations need their own acceptance criteria

The beta announcement describes Ask AI in the Classic package as a Back Office conversational interface connected to the PrestaShop MCP Server. The same announcement identifies PrestaShop Automation with Klaviyo as a Classic distribution integration. These are distribution capabilities whose setup and external dependencies deserve separate evaluation. 9.2 beta announcement.

For Ask AI, the useful starting point is a question with an answer staff can independently verify. “Show the count for this named shop, date interval and order-status set” is a better evaluation than an open-ended request to improve the business. It makes incorrect scope, incomplete results or misunderstood terminology easier to recognize.

For an action, define the affected records and expected values before approving anything. An assistant that interprets a sentence correctly still needs an appropriate execution path and sufficient permissions. Its final message should be checked against the changed store state.

For a marketing integration, separate installation from account readiness. A bundled connector does not establish your audience rules, campaign content, suppression handling or account configuration. Use a synthetic audience and non-delivering test process while evaluating a release candidate. Confirm where events would go before enabling synchronization on a copied database.

These checks are operational recommendations, not claims that a particular provider or module implements every control described here. Treat each integration’s current documentation and installed version as the contract.

Back Office work continues beyond the headline features

The release also matters to people who spend their day configuring and administering stores. The official developer change notes describe another set of Symfony page migrations, exposed through feature flags. They also document an experimental qualification around the new Extra Properties interfaces. 9.2 developer changes.

A migrated page can look familiar while using different extension points underneath. This affects agencies that customize forms, add grid information or modify administrative navigation. The right evaluation asks whether a business operation still succeeds, not whether a particular button still looks the same.

Take a customized administrative form. A field might render correctly but fail to persist, or persist correctly while displaying the wrong shop context on reload. Capture the full round trip: initial value, submitted change, saved value and reopened form. Include an employee account with the permissions normally used by staff.

Do not enable every experiment simultaneously and then attempt to diagnose the resulting differences. Start from an explicit baseline, change one relevant switch, and retain enough evidence to identify the active path. Record the switch state alongside each result so another developer can reproduce the same administrative path.

A practical first review meeting

Give each workflow owner one question to answer before the next meeting. The checkout owner identifies the least certain payment or delivery dependency. The catalog owner selects one field worth modeling. The administrator names one repetitive question with a manually verifiable answer. The developer lists customized pages affected by the candidate.

Review those answers before scheduling a broad testing project. If nobody can identify a current need for a capability, leave it outside the initial experiment. This keeps the release review connected to work the business recognizes and produces a clear reason for each deeper investigation.

Choose a short evaluation path for your store

The best first experiment depends on the store’s constraints. A heavily customized checkout makes payment and delivery behavior the priority. A catalog module with many auxiliary fields makes Extra Properties interesting. An agency maintaining administrative extensions should prioritize migrated page contracts. A merchant considering Ask AI should start with a small set of verifiable questions and a clearly bounded action.

Use a simple decision record:

A failed experiment is still useful if it produces a reproducible incompatibility and a clear next action. A successful demonstration is useful only within the combinations actually exercised. Avoid turning either result into a universal claim about all PrestaShop stores.

PrestaShop 9.2 is therefore worth evaluating as a set of specific workflow changes. Keep the current RC status visible, select the capabilities that solve a real problem, and document the evidence that would justify the next step. Our safe PrestaShop upgrade guide provides background on planning a controlled upgrade; keep any 9.2 RC experiment separate from a production migration.

Frequently asked questions

Should I install PrestaShop 9.2 RC1 on my live store?

Use the release candidate in an isolated testing environment. Its purpose is to validate the upcoming release and identify remaining regressions. Keep your working production installation separate, and disable real payment capture, customer messages and external synchronization in a copied test store before running evaluation scenarios.

Does the native One Page Checkout replace my current checkout automatically?

Do not treat the availability of a native checkout as a replacement plan. First identify the functions supplied by your current checkout, payment modules, delivery integrations and theme. Test the intended configuration explicitly, including address changes, delivery recalculation and payment return paths. Feature availability alone does not establish equivalent behavior.

Which new feature should an agency evaluate first?

Start with the feature that intersects the store's most important customization. That may be checkout behavior, extra entity fields or a migrated administrative page. Choose one business operation, record its expected result, and reproduce it with the relevant employee permissions, shop context and language settings.

Conclusion: make the release review actionable

Choose one workflow, assign its owner and define a result that can be checked independently. Keep the archive and module versions with your test evidence, record unresolved dependencies and decide whether the findings justify a wider trial. This turns interest in PrestaShop 9.2 into a practical evaluation without confusing an encouraging demonstration with production readiness.

Planning your next extension? Browse PrestaSuite’s PrestaShop 9 modules and review each module’s stated compatibility before including it in a 9.2 release-candidate test.