WooCommerce 11.0 Ships With Guest Checkout Account Claim

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

Six days ago the WooCommerce team told everyone their upcoming 11.0 release was slipping by a week because RC1 testing surfaced a fatal error under specific conditions. Yesterday, on August 4, they shipped 11.0.0 on the new date they had committed to. That is not a small thing to notice. Every hosted commerce platform I have watched over the past two decades has had the same choice — ship a known-broken build and quietly hotfix later, or hold the release and tell the world why. The second path costs a public delay. The first path costs your customers a Saturday.

I am writing this from the position of someone whose weekend was not spent narrowing which upgrade broke what. That is the entire pitch of the WooCommerce Core Foundations initiative playing out on the calendar, exactly as advertised. The interesting question this morning is not whether 11.0 shipped. It is what actually landed, and how we sequence it into production.

Here is what I would move on this week, what I would defer, and what I would leave alone.

What is actually new

WooCommerce 11.0.0 shipped on August 4, 2026 — 551 pull requests, 89 contributors, backwards compatible, database update required. Release engineering byline is Brian Coords. The release notes describe the focus as guest checkout, performance, and backlog cleanup, plus a batch of experimental features for developers.

The headline feature is the guest checkout account claim. Logged-in customers can now confirm ownership of an email address and connect their past guest orders to their account. Per the 11.0 pre-release notes, the current implementation moved from an OTP-specific flow to a login-gated confirmation link that aligns with existing WordPress account patterns — a nice reminder that the platform underneath still influences the shape of every feature Woo ships.

The performance work is the second big block. Product object caching is enabled by default for new stores, with pre-release measurements citing variable products loading 9–12% faster on product pages and bundle products processing 6–12% faster during checkout. Existing stores keep their current behaviour and can opt in through settings — default enablement for them is scheduled for a future release. The Store API now limits and de-duplicates product collection-data count requests. The Orders screen gets an HPOS query optimisation for multi-status lists and empty-search counts. Stock status handling during order processing is more reliable. Analytics reporting adds refunds to sales endpoints and lets you retry failed historical imports.

Under the hood, 11.0 upgrades the internal dependency to Action Scheduler 4.0.0. If you rely on Action Scheduler in a custom extension, review your integration before pushing this to production.

Three deprecations to flag. First, the Product Editor beta is fully deprecated — the @woocommerce/product-editor package, its feature flags, and its routes are gone. If you kept an integration alive against that surface, this is the release where it stops working. Second, the Product Image block dropped its Resolution attribute. Third, ReserveStock::reserve_stock_for_order() now defaults to a 60-minute reservation window, and the product shipping class taxonomy is now private.

The experimental features live behind flags at WooCommerce > Settings > Advanced > Features — Abandoned Cart / Checkout recovery, a block-based email editor (this release adds Vimeo, TikTok, and Dailymotion embed rendering as clickable thumbnails), and a React-based Settings UI that gradually upgrades PHP-based settings. Experimental means experimental. These are not the reason to upgrade.

All of this landed on the exact revised date the delay advisory committed to on July 28. That matters more than any single feature.

Why it matters for WordPress and WooCommerce people

The guest checkout claim closes a gap that has been open for years. On stores where a majority of orders come through guest checkout — direct-to-consumer, gift-heavy catalogues, single-purchase categories — the customer eventually creates an account for a warranty, a subscription, or a repeat order. Before 11.0, those past orders were stranded on the guest email address. The claim flow means an account created six months after a guest order can inherit that history without a support ticket. That is a real reduction in support load, and a small nudge toward account creation because the account now offers something the guest checkout does not.

The performance changes are the second thing to notice, especially on stores I would call “loved but neglected” — five-year-old catalogues, tens of thousands of orders, a persistent object cache that was configured once and never revisited. Product object caching on by default for new stores is Woo agreeing that the object cache is now part of the default architecture, not a special-case optimisation. If you build new stores on 11.0, you inherit that assumption. If you inherit an older store, the default did not change — flip the setting on your own schedule, in a separate maintenance window from the version upgrade itself.

The Product Editor beta deprecation is the release-engineering signal. That beta consumed years of contributor time, and Woo has been clear for two releases that it was heading for retirement. Now the code is gone. If your client’s admin still relies on it, the confusion this week will be small and immediate rather than mysterious three months from now. The classic product editor remains the supported surface — see the variation galleries dev note from June for the direction that surface is actively moving in.

The Action Scheduler 4.0.0 bump is the change I would triage most carefully. Action Scheduler is the queue underneath so much of WooCommerce — subscription renewals, webhook deliveries, HPOS background operations, dozens of extensions that piggyback on it. A major version means signatures have changed somewhere. Any custom code that calls as_schedule_single_action, as_next_scheduled_action, or hooks into the queue lifecycle deserves an actual read of the Action Scheduler documentation before the upgrade, not a hopeful wp plugin update.

What I would do (or not do) about it

My upgrade calendar for this week and next, in the order I would execute it.

Today and tomorrow. Clone every managed WooCommerce site into staging and run wp plugin update woocommerce --version=11.0.0. Run the database update. Walk the admin — Orders screen, Products screen, Analytics, Settings. Walk the front end — shop, single product (both simple and variable), cart, checkout (as guest, as logged-in). Nothing exotic yet. You are checking that the fatal-error class that killed RC1 is genuinely fixed on your specific plugin stack.

Later this week. Grep every custom plugin and mu-plugin for direct Action Scheduler API calls and for anything importing from @woocommerce/product-editor. The first list is your queue-integration audit. The second list is code that stops working today — usually a small admin panel or a custom field block someone shipped in 2024. Either delete or rewrite against the classic editor surface.

Week of August 10. Production upgrade on the smaller, less complex managed sites first. Existing stores keep their product object caching setting untouched — do not flip it in the same window as the version upgrade. If a store’s client is asking about it, tell them honestly that this is a two-window change and the second window is next month.

Week of August 17. The larger complex retainer stores. This is deliberately the week WordPress 7.1 GA is landing (August 19), so pick one or the other for each site — you do not want two simultaneous major upgrades in the same triage queue on the same afternoon. Most of my larger clients get WooCommerce 11.0 this week and WordPress 7.1 the week after, keeping change windows sequential rather than stacked.

Two things I would not do. I would not enable any of the three experimental features on a production store this month. Abandoned cart recovery in particular sounds tempting to a marketing-minded client, but experimental means the settings and data model can move underneath you between point releases. Prototype on staging, wait for a formal graduation, then ship. And I would not install any plugin whose entire pitch is “adds a settings UI for WooCommerce 11.0 features”. The features have canonical settings screens. Wrapping them in a third-party layer is exactly the technical debt Core Foundations is trying to retire.

One thing worth doing that is not on any changelog. Send your clients a short note this week acknowledging the delay and the on-time delivery of the revised date. Frame it as what it is — a working release pipeline behaving exactly as designed. That kind of communication is how you build the credit you need the next time an upgrade genuinely does bite.

WooCommerce 11.0 is not a flashy release. It is a foundations release that hit its committed date and put a real feature — the guest order claim — into the checkout flow every store owner has been asking about for years. That combination is exactly what I want from an open-source commerce platform I am going to be running on client production for the rest of this decade.