WooCommerce 11.0 Ships: Guest Orders, Faster Queries

WooCommerce 11.0 shipped on Tuesday, August 4, 2026, a week after the release slipped its original date — 551 merged pull requests from 89 contributors, a required database update, and a release the team itself frames as foundations and backlog cleanup rather than new features. The change most likely to stop your update is not in the release post at all — a WordPress 6.9 minimum — and the one most likely to reach your reporting is an analytics change that moves your numbers without moving your business.

We covered the slip when it happened — WooCommerce postponed 11.0 after a fatal error surfaced in RC1 — and that loop is now closed. This post is not about the week it lost. It is about what landed, what the release notes leave out, and what an agency running several client stores has to check before touching production.

Everything below is sourced from WooCommerce primaries — the developer release notes, the merchant-facing companion post, the pre-release developer brief, the July advisory posts and the raw readme.txt on the release branch — plus the public GitHub and WordPress.org APIs, which supply the release timestamps, the patch history, the backlog counts and the install figure. Where a number is our own count rather than a vendor figure, it is labelled as such. Where a claim depends on a denominator, the denominator is printed with it.

The WooCommerce 11.0 release notes put the date plainly: released August 4, 2026, backwards compatible, database update required, 551 PRs from 89 contributors. Two independent registries corroborate the date — the GitHub release object for the 11.0.0 tag was published at 16:33 UTC on August 4, and the WordPress.org plugin API reports the same day for last_updated.

Author Brian Coords calls it one of the largest WooCommerce releases in recent history on the strength of the PR count. That framing is fair — but four different size numbers are circulating for this release, and none of them are interchangeable.

The clearest read on what kind of release this is comes from the changelog itself. Counting the entries in the 11.0.0 block of the release/11.0 readme.txt and grouping by the label each line carries gives 275 entries, and more than half of them are fixes. That is the quantitative version of foundations and backlog cleanup, and it is a compliment rather than a criticism: a platform this size earns trust by closing issues, not by shipping surface. It is a different kind of release from 10.9, which led with a genuinely new capability when WooCommerce shipped native MCP support in June — and, on the evidence of the changelog, a more useful one for an established store.

WooCommerce 11.0 requires WordPress 6.9 or newer. The release/11.0 readme header reads Requires at least: 6.9, and the WordPress.org plugin API returns the same value. This is a hard install gate — a store still on WordPress 6.8 will not be offered the update — and it is absent from the release notes, absent from the merchant-facing companion post, and absent from every piece of coverage we found. For an agency running several client stores, it is the first thing to check, before compatibility testing and before staging.

The PHP floor is 7.4, which is unlikely to block a maintained host. The readme also declares the release tested up to WordPress 7.0. A note on that number: the WordPress.org directory listing carries a slightly higher tested-up-to value, because maintainers bump the directory field independently of the release branch. Cite the branch readme’s 7.0 when you are describing 11.0 itself.

The headline merchant feature is guest order claiming. In WooCommerce’s own words, customers can now find previous orders and connect them to their user account with email validation. It completes a feature line the platform started in WooCommerce 9.5, which introduced post-checkout account creation in December 2024: 9.5 let a guest become an account holder at the moment of purchase, and 11.0 lets an existing account holder reach backwards and adopt the orders they placed as a guest.

One implementation detail matters more than it looks, because it changed during the beta and the earlier description is still circulating. The first implementation used a one-time passcode. The pre-release developer brief states that a follow-up moved the experience to a login-gated confirmation link that aligns more closely with WordPress account patterns, replacing the OTP-specific endpoints, forms and metadata from the first implementation. If you are writing help-desk copy or a customer email template, describe it as a confirmation link behind a login — not as a one-time code.

WooCommerce frames the merchant benefit as fewer support tickets for stores with meaningful guest checkout volume, plus a reason for returning customers to create an account. That is a vendor marketing claim with no supporting data published, so treat it as a directional argument rather than a forecast — and do not invent a number for it. If guest checkout is a large share of your orders, the honest way to size the benefit is to measure your own “where is my order” ticket volume for a month before you update — which is also good practice for checkout optimisation generally.

Performance is the release’s stated headline: WooCommerce says the work really shines for stores with large catalogs or a deep archive of orders. Two specific figures are published, and they are the most abusable numbers in this release, so here they are with their scopes intact.

Vendor-stated, from the product object caching announcement of June 17 and repeated identically on two further WooCommerce pages: variable products load roughly 9-12% faster on product pages, and bundle products process 6-12% faster during checkout. Neither figure is sitewide, neither covers all product types, and — the part that matters most — both apply only where product object caching is switched on.

The caching itself is narrower than the phrase suggests. It intercepts wc_get_product() calls and serves product objects from a request-scoped in-memory cache; the cache is non-persistent and is cleared between requests, and repeated calls return cloned instances rather than references. It arrived as an experimental feature in WooCommerce 10.5 and its compatibility default flipped from incompatible to compatible in 10.6, so this is a graduation rather than a debut. The compatibility caveat is worth passing to your developer: extensions that run direct SQL against product data can return stale results, while extensions using wc_get_product() and the standard APIs are unaffected.

Two other performance changes in 11.0 apply regardless of the caching setting. The HPOS orders admin list is faster on large stores because multi-status order queries were rewritten as per-status UNIONs — a real mechanism rather than a vague speed-up, and the direct continuation of the HPOS work we walked through in our pre-release upgrade checklist. And Store API collection-data requests are now capped, with attribute and taxonomy count requests de-duplicated to stop a single request triggering an excessive number of database queries. That last one has a sharp edge: headless and custom storefronts that lean hard on collection-data may now receive an HTTP 400, and the new limit is filterable for extensions that need it raised.

This is the part of 11.0 nobody is writing about, and the one most likely to end up in an awkward conversation with a client. Two changes in this release move reported numbers without any change in the underlying business, and a merchant comparing August to July in a board deck will see a step-change caused by measurement.

WooCommerce is refreshingly direct about the first one. In the merchant-facing companion post published on Wednesday, August 5, Brent MacKinnon writes that analytics is stricter about what counts as a visitor so bots and fleeting connections do not pad traffic numbers, that you will see sessions dip slightly after updating and that this is expected, and that you will start seeing more accurate conversion rates. The mechanism is named in the developer brief: analytics events now require a stable visitor ID to avoid inflated sessions from transient or bot clients.

The second change is quieter and lands in the same reports. The v3 sales report gains a refunds value in each date bucket, so per-period net sales calculations are more accurate — a July refund against a June order now shows up in July. WooCommerce’s merchant framing is that month-by-month comparisons become more trustworthy, which is true going forward and also means your historical month-over-month series is not directly comparable across the update. Critically, the change applies to v3 only — existing v1 and v2 consumers are unchanged. If one dashboard reads v3 and another reads v2, the two can now legitimately disagree about the same store.

The practical advice that no vendor post gives is the simplest one: annotate your analytics with the update date before you update, and never compare a pre-11.0 month with a post-11.0 month without saying so in the same sentence as the number. If you report monthly to a client or a board, the update date belongs on the chart. This is exactly the kind of measurement break that a properly instrumented analytics setup treats as an annotated event rather than a mystery.

WooCommerce 11.0 upgrades its internal dependency to Action Scheduler 4.0.0. Merchants do not opt into this — it arrives with the plugin update — and the major-version bump is deliberate, because the release is backwards-incompatible in two ways that are silent unless you go looking. WooCommerce explains the numbering itself: WordPress-style versioning means there is no 3.10 after 3.9.3, and rather than ship breaking changes under a routine-looking 3.9.4 the team bumped to 4.0.0 to flag them clearly.

Change one: failed actions are now purged. Failed actions are deleted by default after three months, where previously they were kept indefinitely. WooCommerce reasons that three months lines up with a typical quarterly accounting cycle. The retention window is tunable via action_scheduler_retention_period_for_failed, and the cleanup can be disabled entirely by returning false from action_scheduler_enable_failed_action_cleanup. If your failure forensics depend on old failed actions still being in the table, that is now a countdown.

Change two: unique-action deduplication now includes arguments. Before 4.0.0, matching meant the same hook and group with arguments ignored, so two actions that differed only in their arguments blocked each other and the second was silently dropped. That is fixed, and the consequence is stated bluntly by WooCommerce: if you relied on the old hook-and-group-only deduplication, expect more actions to be created than before. For a store with custom scheduled jobs, that is a volume change to the busiest tables in the database, and it deserves a look before the update rather than after.

Cleanup also moved from running inline on every queue batch to a dedicated daily job at 3am site time, deleting at least 250 records per run and continuing until the backlog clears. The batch size is tunable via action_scheduler_cleanup_batch_size.

WooCommerce published its breaking-change notices as separate advisory posts across July rather than as one list — thorough of them, and easy to miss. Here they are in one place, with the one that lands in the SEO team’s lap first.

The product shipping class taxonomy is now private

product_shipping_class is registered with 'public' => false in 11.0, so is_taxonomy_viewable('product_shipping_class') now returns false. The advisory for this change names sitemap generation, taxonomy archive handling and query builders as the mechanisms affected, and lists sitemap, SEO, navigation and public query integrations among the code most likely to notice. This is a visibility change, not a data migration — terms, their assignments and shipping rates are untouched — but if your SEO plugin was generating sitemap entries or archive URLs from shipping classes, those will now stop being produced. It is a rare case of a shipping-side change with a search-visibility consequence, which is worth knowing about before a client asks why their URL count fell. One trap: that advisory still says the change is coming in “WooCommerce 11.0, scheduled for July 28” — a stale date left in a live vendor doc. July 28 was the original target, not the release date.

get_queried_object() on the Shop page

On the Shop page, get_queried_object() now returns a WP_Post rather than a WP_Post_Type. Single product pages, product taxonomies and conditionals such as is_shop() and is_post_type_archive('product') are unchanged. Code that needed the post-type object should call get_post_type_object('product') instead.

woocommerce_removed_order_items fires later

The hook now fires at save() time, after the database delete has committed, rather than synchronously inside WC_Abstract_Order::remove_order_items(). The pre-hook woocommerce_remove_order_items is unchanged. The reason is a real bug: an order could previously end up with a correct total but zero line items if a checkout order-resume failed mid-flow. WooCommerce notes there are no consumers of this hook in core itself, so the blast radius is entirely custom code.

Stock behaviour, in two places

Reserved stock now defaults to a 60-minute hold when callers omit the duration. WooCommerce’s merchant framing is that stores running flash sales or drops should have a conversation with their developer about whether 60 minutes suits them — for a high-demand drop, an hour of held inventory per abandoned cart is a meaningful constraint. Separately, and usefully, the changelog records that reduced stock is now restored when an order transitions to failed, so inventory held by an order that reduced stock while on-hold (an accepted-but-pending SEPA or ACH payment, for example) is released instead of staying reduced indefinitely. Stores using delayed-settlement payment methods have been living with that leak.

Smaller surface changes

• The Product Editor Beta is fully removed. The @woocommerce/product-editor package, its feature flag, its editor-specific routes and the related extension points are gone. Affected stores fall back to the classic editor; WooCommerce confirms products and product data remain in place.
• New phone hooks. woocommerce_validate_phone allows custom validation for local formats and non-English numerals, woocommerce_format_phone_number handles presentation without changing validation, and WC_Validation::is_phone_format() offers a country-agnostic shape check.
• Backorder notification control. A new setting enables or disables backorder stock notification emails, with a woocommerce_should_send_backorder_notification filter, mirroring the existing low-stock and out-of-stock notifications.
• Build tooling. @woocommerce/eslint-plugin replaces @woocommerce/dependency-group with import/order, and the Product Image block drops its Resolution attribute in favour of responsive images.

Eleven days before 11.0 shipped, WooCommerce announced a three-month push in which most of its product and engineering teams would focus exclusively on the core plugin. The post that announced it set an unusually specific standard, and 11.0 is the first significant release measured against it.

Held to that bar, 11.0 is a mixed but honest result. It slipped its original Tuesday, July 28 target by seven days. It required a database update. It requires WordPress 6.9 or newer. And the release train ran further than the public record suggests: the GitHub releases API shows beta.2 on Monday, July 20, RC1 on Tuesday, July 28, RC2 the next day, and then a third release candidate on Thursday, July 30 before GA on August 4. The July 28 delay advisory announced only RC2, and at the time of writing we could find no blog post announcing RC3 at all — it is visible to anyone who checks the free releases API, and it appears in none of the coverage we read.

The reason for the slip is the release’s own uncomfortable symmetry. WooCommerce’s delay advisory states that during early testing of 11.0.0 RC1 the team identified a fatal error under specific circumstances from a new performance feature — and performance is the release’s banner. WooCommerce never identified which feature, and at the time of writing no follow-up advisory names it. The obvious suspicion is the flagship caching work, but that is a suspicion and not a source, so the fair thing to say is the tension itself: the feature that headlines this release is the same class of feature that delayed it.

The counter-evidence is just as sourced, and it favours WooCommerce. At the time of writing there is no 11.0.1 — a tag lookup for it returns a 404 and the WordPress.org API still reports 11.0.0 as the current version. That is notable, because each recent minor we checked drew its first patch within days. Treat the last row of this table as provisional; a patch could land at any time.

GA and patch dates are values from the GitHub releases API; the day counts are ours, computed from those dates. The 10.9 line is the useful comparison for anyone deciding how long to wait: it took a patch the day after release and went on to three more across early July. A quiet first week is the best available signal that 11.0 is behaving — and, this early, the only one.

The backlog story behind all of this deserves its numbers handled carefully. WooCommerce stated that when the core-only push started there were over 2,300 open issues and 500 open pull requests on the repository. Our own read of the GitHub search API at the time of writing returned 1,375 open issues and 552 open pull requests. Three caveats have to travel with that comparison or it should not be made at all. First, the vendor baseline is undated — the announcement post says the push had just kicked off and gives no measurement date. Second, and most importantly, WooCommerce’s own process says each backlog item is either added to a prioritised list or closed with a clear reason and an invitation to reopen it, so a falling issue count is emphatically not evidence of bugs fixed. Third, it is a snapshot of a number that moves daily. Note also that the pull-request count went up, not down.

Read honestly, the burn-down says the backlog is being triaged, which is what WooCommerce said it would do. What it does not say is that the software got better by that proportion, and anyone presenting it that way is over-reading a queue length.

WooCommerce’s requirements live in the readme header, its breaking changes live in scattered advisory posts, and its bundled dependency has its own announcement. No single vendor page merges them. This table does — split into the checks that will stop the update or visibly break something, and the ones that only matter if the description matches your stack.

The other half of the gate is knowing what to leave switched off. Three features associated with 11.0 are experimental or in beta, and none of them should be enabled on a production store on the strength of a release announcement.

None of this is a reason to skip 11.0. It is a reason to run it the way you would run any platform release: staging first, one client store as a canary, a week of watching, then the rest. If you are weighing the update alongside a bigger platform question — and Shopify reported growth to shareholders the same week WooCommerce shipped a backlog-cleanup release — the two events are a neat illustration of what platform progress means on each side of that fence. Our WooCommerce versus Shopify comparison covers that trade-off properly.