PrestaShop 9.2: what actually changes for your store

Introduction

PrestaShop 9.2 entered feature freeze on 9 July 2026, and beta 1 shipped on 22 July 2026. Three features carry this release: a native One Page Checkout, an Extra Properties system for extending core entities, and an Ask AI assistant in the back office. No stable release date has been announced so far.

On paper, that is a strong list. The context deserves setting out, because two contradictory stories circulate about PrestaShop and both are true.

The platform is losing stores. 218,906 live at the end of 2021, 151,810 on 14 August 2026, meaning 31% fewer in under five years. In France it now captures only 5.4% of new store creations, against 48.8% for Shopify.

And it remains France's leading platform by revenue. Ahead of Shopify, ahead of WooCommerce, with fewer stores than either.

An average PrestaShop store weighs 1.6 times a Shopify store and 4 times a WooCommerce store. The reading writes itself: PrestaShop is losing the small stores and keeping the large ones. The count falls, the weight rises.

That is the landscape 9.2 ships into. Our own database holds 818 PrestaShop stores registered since 2018, of which 280 were active in the last twelve months, against those 24,211 French stores. We do not claim to describe the whole market, we describe what passes through our hands.

The platform changed hands in February 2026

You cannot discuss the pace of 9.2 without this, and it explains much of the revival people mention.

On 18 February 2026, Polish group cyber_Folks completed the acquisition of 100% of PrestaShop for roughly €53.7 million, on an agreement signed 11 December 2025. The deal runs through a holding, cyber_Pixel, 79% owned by cyber_Folks, which now gathers PrestaShop alongside Sylius and BitBag, two players from the same PHP ecosystem. The heads of Sylius and BitBag joined PrestaShop's board.

The stated logic is a product ladder: Shoper for very small businesses, PrestaShop for SMEs, Sylius for composable projects and large accounts. In other words, PrestaShop stays on its historic segment instead of chasing the upper market.

What the calendar shows

The dates speak. The acquisition closes on 18 February. 9.1 ships stable on 23 March, one month later. The 9.2 freeze lands on 9 July, its beta on 22 July. Above all, the cycle shortened: 120 days from beta to stable for 9.0, 75 days for 9.1.

Correlation is not causation, and part of that work was under way before the sale. Still, the pace picked up as ownership changed, and two major versions shipped within eighteen months after several slower years.

One shadow, worth stating to stay honest: a redundancy process was announced on 10 April 2026, eight weeks after closing, across a headcount of roughly 347. Neither the number of positions nor the teams involved were disclosed, and the procedure remains subject to approval. For anyone planning a migration, that is a schedule risk factor alongside the count of open tickets.

This article does three things. It details what 9.2 actually brings, feature by feature. For each one, it states what that will cost a live store, based on what we see break on checkouts, payment modules and carriers. And it holds the announcements against the real state of the GitHub repository: milestone progress, the pace of previous cycles, and the maturity of the checkout module, which holds a surprise.

Method — The features described come from the official beta 1 announcement of 22 July 2026 and the feature freeze notes of 9 July 2026, published on the PrestaShop developers' blog. They cover the Classic edition. Operational figures come from our support platform: 9,280 tickets closed or in progress between 11 October 2018 and 20 August 2026, of which 3,395 are tied to an identified PrestaShop store, Our database holds 818 PrestaShop stores registered since inception, of which 697 have sent at least one request and 280 did so in the last twelve months: that last figure describes the genuinely active base. Market figures come from three separate sources: the StoreLeads PrestaShop report of 14 August 2026 for worldwide store counts and trend, the Friends of Presta benchmark of 26 March 2026 for France, built on 125,512 active e-commerce sites and 110,661 companies identified by SIREN, and public communications about the acquisition. Average revenue per store is our own calculation from the benchmark.

Where PrestaShop 9.2 actually stands

The known schedule fits in three dates. On 9 July 2026, the 9.2.x branch was created and scope was frozen: no further features get in. On 22 July 2026, beta 1 was published for the Classic edition, as prestashop_edition_classic_version_9.2.0-beta.1.zip. After that, nothing official.

One detail in that announcement deserves a second read: there is no upgrade path from the beta to the RC or to the stable release. A store installed on the beta is a dead end. It serves to test, to report issues, to prepare a module. It does not serve to start a project you intend to launch.

More than fifty contributors are credited on this beta. That is a good signal on project health, and a poor indicator of maturity: a beta with fifty contributors is a beta where a lot of new code meets for the first time.

Roadmap versus reality: what the repository says

Announcements state intent. The GitHub repository states status. We recorded both on 21 August 2026, one month to the day after the beta.

What previous cycles let us predict

PrestaShop publishes no release date. The two previous major cycles, however, are dated to the day by the repository's own releases.

At the 9.1 pace, stable would land in early October 2026. At the 9.0 pace, closer to mid-November. These are projections rather than announcements, and they assume the project keeps its cadence.

A useful marker: on day thirty of the 9.1 cycle, the RC was still twenty-seven days away. So 9.2 is not late, it is on time against a schedule nobody published.

Progress, in repository figures

• The 9.2.0 milestone holds 211 open items against 459 closed, meaning 69% done. One month after a beta, two hundred and eleven remaining items says an RC is not imminent.

• 209 open pull requests target the 9.2.x branch. Among the hundred most recent PRs in the repository, seventy-eight aim at it: that is where the work sits.

• 98 commits landed on 9.2.x since the beta, one of them on the morning of our check. The branch is actively alive.

• The 9.3.0 milestone is already open, at 39% (97 open, 62 closed). The project is working on the next version before shipping this one, which is normal, and worth knowing when you plan.

The One Page Checkout is at version 0.6

This is the finding that should drive your timeline, and it appears in no announcement.

The module lives in its own repository, PrestaShop/ps_onepagecheckout, created on 5 March 2026. Its latest published version is v0.6.5, dated 27 July 2026, flagged prerelease, as were the five before it. No 1.0 exists. The repository carries 6 open issues and 15 pending pull requests.

The content of those issues speaks better than any commentary. Two examples, as reported:

#144, opened 31 July 2026: the selected carrier is silently lost after a temporary address cleanup, and payment options display incorrectly.

#149, opened 19 August 2026: ticking "use this address for invoice too" replaces the customer's saved address.

Add to that a consent checkbox stack where terms get accepted twice (#102), and duplicate HTML ids between the address modal and the inline forms (#94). That last one deserves an integrator's attention: a duplicate id breaks accessibility and any third-party script keyed to it.

None of these defects is damning for a module of this age. All of them are damning on a live checkout. A carrier silently lost means orders lost with no error message, therefore no complaint, therefore no way for you to know.

Native One Page Checkout: the change that touches the most stores

PrestaShop finally ships a single-page checkout as a native module in the distribution. The feature had been announced for 9.1, then postponed. It is in the 9.2 beta.

The principle: no more successive steps, no page reloads, and a guest-first experience, meaning oriented toward buying without creating an account first. Fields update dynamically as the customer types.

Why this feature is also the one that breaks the most

This is the part announcements skip. Checkout is where the most third-party code meets: payment modules, shipping modules, delivery cost calculation, pickup points, discount codes, VAT, gift options, insurance. Each was written against a multi-step checkout, with page reloads at specific moments.

Our figures give a sense of the ground involved. Among tickets mentioning PrestaShop, 839 concern the checkout, the cart or the order, 357 a payment method and 211 a carrier or delivery. Those are the three families the One Page Checkout cuts straight through.

PrestaShop publishes dedicated documentation for payment and shipping module developers, and for theme authors. That is necessary, and it says the essential part: a module that has not been adapted will not behave correctly in the new checkout. The question to put to your vendors is not "are you 9.2 compatible", it is "have you adapted your module to the One Page Checkout".

What this means for your store in practice

The new checkout ships as a module. So you keep the option of staying on the historic funnel. That is the only good news in this section, and it matters: switching will be a decision, not a side effect of updating.

If you do want to enable it, the sensible sequence looks like this. Inventory every module involved in checkout, including the ones you forgot you had. Ask each vendor for their compatibility status, in writing. Test on a copy, with real orders in each payment provider's test environment. Then measure: a single-page checkout does not mechanically raise conversion, it changes how abandonment happens.

We installed the beta. Here is what reading the announcements does not tell you

Everything above comes from public sources. This section comes from a machine. We stood up the 9.2 beta on 21 August 2026, from the official image prestashop/prestashop:9.2.0-6.0-beta.1-classic-8.5-apache, on PHP 8.5.0, the version the documentation recommends, with MySQL 8.0.46. The installed shop reports PS_INSTALL_VERSION = 9.2.0.

It took four attempts to install

No two failed the same way, and the first three are reproducible by anyone testing the beta in Docker, which means almost everyone.

1. Renaming the admin folder breaks the install. That is the first security measure any serious integrator takes. The installer stops on The target directory "/var/www/html/admin-dev" does not exist. The cause sits in Install::finalize(): the variable starts at the hardcoded value admin-dev, and is replaced only if a folder named /admin/ still exists. Once it has been renamed, the installer looks for a folder that never existed. The same code is in 9.0: this is not a 9.2 regression, it is long-standing behaviour.

2. Without a volume, the automatic rename fails. With the default folder, the installer tries to rename it randomly, which is good practice. The operation returns Invalid cross-device link. The reason is worth knowing: overlayfs, Docker's filesystem, cannot rename a directory inherited from a lower image layer. The fix is to mount the web root on a volume.

3. A successful install still kills the container. The core logs "Installation successful", removes the install/ folder, then the image entrypoint tries to remove it in turn, fails on rm: cannot remove '/var/www/html/install/': No such file or directory and exits with an error. The container stops right before Apache starts.

4. A plain restart then works. Sixteen seconds later, the shop answers in 0.23 s.

None of this is dramatic on a test environment. All of it costs half a day to whoever discovers it.

What the beta actually ships

81 modules on disk, 80 registered in the database. The versions of the new features deserve a close read.

The bundled One Page Checkout is 0.6.2, while the module's own repository had already published 0.6.5 on 27 July. The beta therefore carries an earlier build of its own flagship feature.

Good news on the other hand, and checkable in the database: PS_ONE_PAGE_CHECKOUT_ENABLED is 0. The module is installed and active, the single-page checkout stays off. Nobody will switch by accident while updating.

The checkout resets the customer's country to United States

Here is our main finding, and it is reported nowhere.

We enabled the single-page checkout on a shop installed in French, default country France, then filled a cart as an unidentified visitor. The server sends a correct form: all four country selects on the page carry France as the selected value. After JavaScript runs, the visible field shows United States.

Measurement — HTML served by the server: France selected. DOM read after scripts execute: United States selected. Reproduced twice, with a fresh browser profile and a fresh cart each time. Module ps_onepagecheckout 0.6.2, PrestaShop 9.2.0 beta, PHP 8.5.

On a French shop, that changes the VAT applied, the carriers offered and the shipping costs calculated. A customer who does not check that field is offered a delivery that is not theirs. A merchant testing quickly will not see it either, because the HTML itself is correct.

This is exactly the kind of defect no reading of release notes reveals, and only a real run catches.

Duplicate ids, measured

The module repository reports duplicate HTML ids between the address modal and the inline forms. We counted on a stock install: 24 duplicate ids on the checkout page, including field-alias, field-firstname and field-lastname. The page renders four country selects where the customer sees one.

For an integrator, that is operational information: any third-party script targeting those elements by id, which is what many pickup-point and address-autocomplete modules do, will hit the wrong field.

The consent block, as it renders

Before entering an address, an unidentified visitor meets three checkboxes and a legal paragraph: partner offers, terms and privacy policy, a note on customer data confidentiality, newsletter signup. The whole stack occupies the first screen, above the address form. On a French install, that paragraph still renders in English, as do the reassurance blocks in the right-hand column.

Ask AI starts on its own, and leans on the PrestaShop account

The MCP server is active from install: PS_MCP_SERVER_STARTED is 1. Two modules make it up, ps_mcp_server for the protocol and ps_mcp_tools for the exposed tools. The configuration reveals a link to PrestaShop Accounts and CloudSync, an anonymous tracking setting, and a PS_MCP_SERVER_AUTH_DISABLED key, left empty by default.

Two things to remember for anyone handling customer data. The assistant only works once a provider is configured, so nothing leaves before that decision. And the existence of a switch able to disable MCP server authentication deserves a check before any production rollout, exactly as one checks that debug mode is off.

Extra Properties: the real structural change for developers

This is the least spectacular feature on the list, and probably the most important over five years. It comes from a collaboration between Kiwik and PrestaShop SA.

The problem it solves is as old as the platform. Adding a custom field to a product, a customer or an order meant creating your own table, writing your own queries, handling multistore and multilanguage yourself, wiring hooks for back-office display, and redoing all of it at every major version. Every in-house module reinvented the same plumbing, with its own bugs.

Extra Properties provides that mechanism natively. Core entities (product, combination, customer, order, among others) accept additional properties with no table to create, with multistore and multilanguage handled, and exposure across the three surfaces that matter: back office, Admin API and front office.

Why it matters even if you do not write code

A poorly implemented custom field is invisible debt. It stays quiet while everything works, and surfaces at migration time: the in-house table is not migrated, the data remains, and nothing reads it any more. We count only 5 tickets that explicitly mention a custom field, and that figure misleads. Those fields almost never break on their own, they break alongside something else, and the ticket then carries the name of the something else.

The practical consequence: on any new custom development, require Extra Properties rather than an in-house table. On existing stores, migrating what is already there is a real question with no automatic answer.

Ask AI: an in-admin assistant backed by an MCP server

PrestaShop 9.2 introduces a conversational panel directly in the administration. It runs on the PrestaShop MCP Server, an implementation of the Model Context Protocol, and works with several model providers: ChatGPT, Claude, Gemini, and other compatible ones. It is included in the Classic edition.

The design point that reassures: the assistant asks for approval before acting on the store. It proposes, you confirm. That is the right way to do it, and the only acceptable one on a system holding a catalogue, orders and customer data.

Two separate things that get confused

Ask AI targets merchants, in the back office. Alongside it, PrestaShop also ships tooling for AI-assisted development: an .ai/ folder versioned in the repository, a CONTEXT.md file describing the project's architecture and conventions, and pointer files (CLAUDE.md, AGENTS.md, .cursorrules) redirecting to it so every tool finds the same context.

Those files are text in Git. No model is embedded in PrestaShop, and no store data leaves for a provider merely because they exist. Developers keep their choice of tool.

The limit is the one every assistant has: generated code still needs review. On PrestaShop, two areas concentrate the mistakes, multistore and hooks. A model happily produces code that works on a single store and fails silently as soon as there are two.

The Symfony pages reaching stable

Migrating the back office from the legacy stack to Symfony has been running page by page for several versions. In 9.2, six screens reach stable: Countries, Merchandise Return, Hook a Module, Quick Access, Email Body Translations and Tax Rules.

"Stable" has a precise meaning here: these pages remain behind the feature flags in the "New & Experimental Features" section. They are not forced on you.

The benefit for a merchant is indirect and real. Every migrated screen is one screen that stops depending on legacy code, so one screen fewer to break at the next major upgrade. The benefit for a developer is immediate: a module grafting content onto one of these pages must verify its behaviour in both modes, legacy and new.

Multi-shipment: the quiet workstream

Almost no article mentions it, yet it is the most worked-on part of this release on the order side. Shipment handling gains a genuine multi-shipment mode: creating a shipment on an existing order, modal-based handling, soft delete, invoice integration, and correct behaviour when products are removed.

For any store shipping in several parts, on partial stock or from several warehouses, that is more useful day to day than a conversational assistant. Our 211 delivery tickets hold their share of orders split in two and invoices that failed to follow.

Klaviyo back in the Classic distribution

PrestaShop Automation with Klaviyo returns natively to the Classic edition: email, SMS, automated campaigns and audience segmentation on store data. Assess it as a marketing module, with the usual questions about what data goes to a third party and on what legal basis.

The technical floor

PrestaShop 9 runs on Symfony 6.4 LTS. Here are the official requirements, as published in the developer documentation.

Two rows in that table cause most of the blockers we see.

The PHP upper bound reads as badly as the lower one. A host that has just moved its servers to PHP 8.6 puts the store outside supported versions, exactly like a host still on 7.4. The problem is not being old, it is being outside the window.

allow_url_fopen is the kind of setting a host disables in the name of security, without notice. The store runs, the catalogue displays, and only payments fail. We see this come back regularly in our payment tickets, and it cannot be diagnosed from the back office.

This floor is the real entry gate. A store on PHP 7.4 with shared hosting does not upgrade to PrestaShop 9, it changes environment first. In our tickets, that is regularly where the project stops, rather than at the migration itself.

Should you migrate now?

No, and you should prepare now. Both statements hold together.

No, because no stable release is announced, because the beta offers no upgrade path to what follows, and because the checkout module itself sits at version 0.6 with open defects on carrier selection and invoice addresses. A store that sells has nothing to gain from going first.

Prepare, because waiting has a price. Our peak in PrestaShop migration requests was 2022, with 111 tickets. In 2026 we are at 36. The drop does not mean the install base is current, it means many stores stopped moving. And a store skipping two major versions is not doing a migration, it is doing a rebuild.

The sequence we recommend

1. Check your PHP and database versions today. It is free, it takes five minutes, and it decides whether this is an update or a move.

2. Inventory every checkout module. Payment, shipping, pickup points, promotions, VAT. Note the vendor, the installed version and the date of the last update. Abandoned modules reveal themselves here, not on switchover day.

3. Ask vendors in writing about 9.2 compatibility and, separately, about One Page Checkout adaptation. These are two different questions.

4. List your custom fields and in-house tables. This is the item that surprises people most during migrations, because nobody remembers creating them.

5. Stand up a test copy from the RC onward, not before. The beta does not upgrade.

6. Wait for a patch release before moving production. The .1 and .2 exist for a reason.

Frequently asked questions about PrestaShop 9.2

When is PrestaShop 9.2 released as stable?

No date is announced. Beta 1 dates from 22 July 2026 and the feature freeze from 9 July 2026. The two previous cycles give an order of magnitude: 75 days from beta to stable for 9.1, 120 days for 9.0. Applied to 9.2, that places stable between early October and mid-November 2026. As of 21 August, no release candidate is out and the 9.2.0 milestone sits at 69% done.

Can a 9.1 store be updated to 9.2?

Not today, since 9.2 only exists as a beta. More importantly, an install made on the beta cannot be updated to the RC or the stable release: that is stated in the official announcement. A beta belongs on a disposable copy.

Will the One Page Checkout enable itself?

No. It arrives as a module. The multi-step checkout stays available, and the switch is a decision you make, payment module by payment module.

Will my PrestaShop 8 modules work on 9.2?

Those are two separate questions, and both go to every vendor. PrestaShop 9 compatibility is about adapting to Symfony 6.4 and to core APIs. One Page Checkout adaptation is additional, specific work affecting only modules involved in checkout. A module can be perfectly 9.2 compatible and unusable in the new checkout.

Does Ask AI send my data to OpenAI or Anthropic?

Ask AI runs with the provider you configure, so exchanges go to the one you chose. That is a decision to record in your processing register, like any other subprocessor. It differs from the .ai/ folder aimed at developers, which is text versioned in Git and emits nothing by itself.

Do I need to go through 9.0 and 9.1 before 9.2?

The question mainly concerns stores on 1.7 or 8. Version jumps are prepared in stages, testing at each one, because that is when abandoned modules reveal themselves. A store on 1.6 is a rebuild project rather than an update.

Does Extra Properties replace my existing custom fields?

It offers the right way to create them from now on. Migrating what already exists, whether in-house tables or custom field modules, has no automatic path and is handled case by case.

What to take away

PrestaShop 9.2 is an infrastructure release dressed as a feature release. The One Page Checkout will get the attention, Extra Properties will durably change how custom work is written, and the Symfony migrations reduce debt version after version.

The schedule stays open. The 22 July 2026 beta is an invitation to test, not to deploy. Until stable, the useful work is on your server floor and on the inventory of your checkout modules, two efforts that depend on no release date.

If your store still runs 1.6 or 1.7, the question is no longer when to move to 9.2. It is how much longer you can hold on a codebase the vendor no longer fixes.

Migrating takes weeks, sometimes months when checkout modules lag behind. Meanwhile, a store on an unsupported version stays exposed to known vulnerabilities, the ones whose exploit code circulates. That is the gap virtual patching fills: rather than editing a core that will receive no further update, exploitation is blocked at the application firewall and in-house patches are applied to published vulnerabilities. Our PrestaSecure module covers PrestaShop 1.6 through 9 for exactly that reason: the real install base is not up to date, and it still has to be protected as it is.

This is not an alternative to migrating. It is what lets you prepare the migration without doing it in a hurry, after an incident.