WooCommerce 11.0: What to Fix Before the July 28 GA

WooCommerce 11.0 reached its first beta on July 13, 2026, when the team published its “what’s coming for developers” pre-release notes on the official WooCommerce Developer Blog — and the headline is consolidation, not novelty. Twenty-eight pull requests in this release are tagged for performance, caching, or scalability, the single largest thematic cluster in 11.0.

Two changes deserve most of your attention before the scheduled July 28 general availability. First, the block-based Product Editor beta — the entire package, its feature flag, its routes, and its extension points — is being fully removed from core. That’s deletion, not deprecation, and extension authors who reference it will hit JavaScript errors after upgrade. Second, Checkout Recovery graduates from concept to a real, still-beta recovery-email flow — the first native cart and checkout-abandonment tool WooCommerce has ever shipped.

This guide covers the release window and cadence, the performance cluster (including which claims are vendor-stated), exactly what code gets deleted with the product editor, how Checkout Recovery works today, the breaking changes extension developers should grep for, and a store-type-segmented checklist for the two weeks before GA. It builds on our WooCommerce 10.9 coverage — the release that opened this deprecation window.

The timing follows WooCommerce’s published release cadence, in effect since September 2024: a 5-week cycle where betas ship on Mondays and major releases land on Tuesdays. That’s why the July 13 beta (a Monday) lines up with a July 28 GA (a Tuesday). The schedule is vendor-announced — 11.0 has not shipped as of this writing, and dates can slip — but the cadence has held consistently enough that “before July 28” is the right working deadline for store owners and extension authors.

Testing is open now. Install the WooCommerce Beta Tester plugin, switch to the Beta channel, and update to 11.0.0-beta.1 on a staging copy of your store. Two weeks is a tight but workable window for the audits this release actually requires — which is the point of the checklist in section 07.

Twenty-eight pull requests in 11.0 carry performance, caching, or scalability tags — more than any other theme in the release. The work concentrates where large stores actually feel pain: the Orders admin screen, catalog pages, the products list, and point-of-sale catalog generation.

The High-Performance Order Storage (HPOS) work targets the Orders-screen queries behind multi-status order lists and empty-search counts — the operations that get slower as order volume grows. WooCommerce hasn’t published a specific speedup figure for this 11.0 optimization, so resist any percentage you see attached to it; the change is aimed squarely at larger stores where those admin queries dominate.

Existing stores don’t get product object caching switched on automatically — the default applies to new stores. If you run variable-product-heavy or bundle-heavy catalogs, the sensible move is to test the caching behavior on staging during the beta window and measure page loads yourself rather than assuming the vendor-stated range transfers to your stack, your host, and your plugin mix.

Most secondary coverage says the block-based Product Editor beta is “retiring” in 11.0. That undersells what’s happening. The GitHub tracking issue (#65319, opened May 26, 2026) confirms the technical scope: the packages/js/product-editor package is deleted from core, the admin consumer at client/admin/client/products/ (including product-page.tsx and product-variation-page.tsx) is removed, the feature is stripped from FeaturesController and from Settings → Advanced → Features, and the editor’s routing and menu entries go with it. Two packages are formally deprecated: @woocommerce/product-editor and @woocommerce/create-product-editor-block.

The classic Product Editor is now the only editor. Product data itself is unaffected — only the editing UI is removed, so there is no migration to run. The deprecation window opened in WooCommerce 10.9 (released June 23, 2026), which added an in-product notice warning admins of the coming removal plus a one-click “switch to classic editor” option. From notice to removal is five weeks — a short window by platform standards, but a clean one.

WooCommerce’s stated rationale, paraphrasing the team’s June 2 retirement post: the block-based editor didn’t prove to be the right foundation for where product editing needs to go, and future work will build on WordPress’s newer DataViews and DataForms interface primitives, which the team sees as a better fit for commerce-specific complexity — variations, inventory, pricing, and extension surfaces. The removal also fixes a real bug: the wcadmin_product_add_view analytics event previously fired from two code paths (classic and block editor) with inconsistent data shapes; deleting the block-editor consumer eliminates the duplicate.

Checkout Recovery is the release’s most strategically interesting feature, and also its most modest in current form. In 11.0 it remains a beta, experimental feature — not GA. What it does today: merchants can manually trigger a recovery email from an eligible order. That’s it. No automated sequences, no send-time optimization, no revenue dashboard. But it’s the first time WooCommerce has shipped a cart and checkout-abandonment tool in core rather than leaving the category entirely to extensions.

The developer surface is already extensible. The woocommerce_checkout_recovery_eligible_statuses filter lets developers widen or narrow which order statuses qualify for recovery emails. The flow ships with a one-click unsubscribe path, a personalization tag for the unsubscribe URL, and updated privacy handling across both the email-trigger and manual-send paths — signals that the team is building the compliance plumbing before the automation.

If abandonment recovery matters to your revenue line — and for most stores it should — the beta is worth testing on staging now, but it’s not a replacement for a mature recovery stack yet. Pair the feature-watch with the fundamentals in our guide to checkout-abandonment recovery tactics, and if you want a second set of eyes on your funnel, our eCommerce services team runs exactly these checkout audits.

Beyond the product-editor deletion, the pre-release notes flag a cluster of compatibility changes that will bite quietly if unaudited:

• Stock reservations. ReserveStock::reserve_stock_for_order() now defaults to a 60-minute reservation window. If your checkout or inventory-sync code assumed a different window, verify the behavior on staging.
• Linting. @woocommerce/eslint-plugin replaces the @woocommerce/dependency-group rule with the standard import/order — expect lint churn in extension CI pipelines.
• Product Image block. The Resolution attribute is dropped in favor of standardized responsive images — check any theme or block templates that set it explicitly.
• Shop page query object. get_queried_object() on the Shop page now returns WP_Post instead of WP_Post_Type — code that type-checks or reads post-type properties there will break.
• Shipping classes. The product shipping-class taxonomy is becoming private — audit anything that queries it as a public taxonomy.

The release also adds, rather than removes, one developer surface worth knowing: phone-number handling gets woocommerce_validate_phone for custom local-format validation, woocommerce_format_phone_number for presentation, and WC_Validation::is_phone_format() for country-agnostic shape validation. Checkout-field customizers finally get first-party hooks instead of regex hacks.

The rest of the release is quality-of-life work that compounds for operators. On the email side, a new woocommerce_email_preview_show_shipping_details filter hides irrelevant dummy shipping details in email previews, and the Block Email Editor gains embed support for Vimeo, TikTok, and Dailymotion — rendered as clickable thumbnails in transactional and marketing emails.

Accounts get a meaningful flow change: logged-in customers can now confirm address ownership via email verification and link past guest orders to their account, migrating from OTP-specific endpoints to login-gated confirmation links. For stores with heavy guest-checkout volume, that’s a direct path to richer customer records without forcing registration at purchase.

Reporting gets three fixes operators have wanted for a while: failed Historical Analytics import jobs now surface in wp-admin with a retry path (via new REST endpoints GET /wc-analytics/imports/status and POST /wc-analytics/imports/retry-failed), the v3 sales report adds a refunds value per date bucket for more accurate net-sales math, and analytics events now require a stable visitor ID to prevent inflated session counts. If your dashboards reconcile WooCommerce analytics against an external source, expect small but real movements in session and net-sales figures after upgrade — for the better.

Official posts organize this release by feature area and news coverage organizes it by headline. Neither answers the question a store owner actually has: what does my store need to do before GA? The table below segments the release by reader — built from the official removal scope, the pre-release notes, and independent practical-impact analysis.

One nuance worth restating: the five-week deprecation clock (June 23 notice in 10.9 to the scheduled July 28 removal) applies to merchants who had the editor toggle on. Extension authors got their warning earlier — the retirement post landed June 2 — which is where the roughly five-to-six-week audit window in independent coverage comes from.

Read as a whole, 11.0 is a maturity release. The single biggest engineering investment went into performance and scalability for larger stores; the single biggest product decision was killing an ambitious rewrite that wasn’t working rather than letting it limp along as a permanent beta. Independent commentary framed the product-editor call as low-disruption for most stores and a sign of process discipline — clean notice, no data migration, an explicit grep list. That’s the behavior of a platform optimizing for the trust of the businesses already running on it, which matters when WooCommerce’s core pitch against hosted rivals is ownership and continuity. For readers weighing that trade-off, our breakdown of how WooCommerce compares to Shopify in 2026 covers the platform-choice question in depth — and the stakes are large given WordPress’s continued market dominance as the substrate under a huge share of the world’s stores.

Looking forward, two threads are worth watching. First, Checkout Recovery’s trajectory: a manual-send beta with an eligibility filter and privacy plumbing looks like the foundation for automated recovery sequences in core, which would put pressure on a whole category of paid abandonment extensions once it matures — though WooCommerce has announced no timeline for that, and betas can stall. Second, the DataViews/DataForms bet: the team retired the block editor in favor of WordPress’s newer interface primitives, so the next product-editing experience will likely arrive as incremental DataViews-based screens rather than another big-bang editor rewrite. Extension authors who align with those primitives early are positioned for whatever ships next; teams planning store builds on this stack can lean on our web development services for the architecture calls.