WooCommerce 11.1: What’s coming for developers

Beta

WooCommerce 11.1 is coming soon

This release is now available for testing. Review the highlights below, test the beta, and share feedback before the final release.

Highlights

  • REST API has a new refund endpoint
  • EU order withdrawal comes to WooCommerce
  • Variable product performance has been improved
  • Beta available now
  • Final release: September 01, 2026
  • Feedback requested

WooCommerce 11.1 brings a complete order withdrawal flow for shoppers, a new REST API refund calculation endpoint, several bug fixes for the product CSV import and export, and a focused set of compatibility changes for extension developers. Here is an early look at the changes taking shape before the release.

Product CSV import and export

PRs: #66903, #66213, #66946, #66205, #66295

Several bug fixes were applied to Product Importing, including preserving terms and categories in re-uploads, clearing images when the file indicates so, respecting existing store currency settings, and better handling for variation creation if the product already exists.

Order withdrawal

WooCommerce 11.1 brings the right of order withdrawal functionality to better serve EU customers. A customer can request a withdrawal from a new My Account page /my-account/withdraw-order/, no auth required. Submissions are then routed to merchants, who receive an email and an inbox notification to follow up with the customer. Order withdrawal is disabled by default and must be enabled from WooCommerce -> Settings -> Advanced -> Features.

REST API refunds and Store API checkout totals

We have updated the refund flow in the WC REST API. We now call POST /wc/v3/orders/{id}/refunds with compute_totals: true in the body, which lets the server calculate the refund totals for you (instead of doing manual calculations).

A new endpoint POST /wc/v3/orders/{id}/refunds/preview allows you to run the calculation and preview the refund without actually applying it.

On Store API, checkout endpoints gain an optional expected_total: integer field that should contain the total the customer is seeing, and if they get charged a different amount, the request would fail with a new 409 woocommerce_rest_checkout_total_mismatch response. This field is then immediately applied in the Checkout block.

Email editor updates

PRs: #66968, #66937, #67079, #66801, #66727

The block email editor makes core/embed insertable for providers that render clickable thumbnails: YouTube, Vimeo, VideoPress, TikTok, and Dailymotion, plus the WordPress embed, which renders as a rich link card. Audio providers are excluded. Embeds from unsupported providers can still be pasted in; however, the editor issues a warning and sends a link to reflect the delivered result.

Personalization tag callbacks now receive their destination content type. A tag can escape correctly for HTML, plain text, or an href. The new parameter is optional and defaults to HTML; automatic escaping applies only to newly registered text-typed tags.

Variable product performance

PRs: #66084, #66675, #66767, #66774, #67152, #66875

Multiple performance fixes are included in this release, mainly reducing N+1 queries around variations and attributes in both the editor and frontend, and reducing queries on price caching as well.

Block registration is skipped on non-rendering requests

PR: #65781, #66672

Block types and patterns previously registered on nearly every request, including many that never render or edit blocks. A new BlockRegistrationContext guard now skips registration on cron, AJAX, and REST API requests, while preserving front-end, admin, and editor behavior.


One exception is built in: when a product or variation description contains a WooCommerce block, block types are registered on demand via the woocommerce_short_description filter, so descriptions still render correctly in the products REST API, the Store API, the variation AJAX endpoint, and product webhooks.

Extensions that assume block registration on every request must adapt. The new woocommerce_should_register_blocks filter opts back in for extensions that render blocks in a skipped context.

Experimental features

Unified block editor assets

PRs: #66200, #67055, #67365

An experimental unified block editor assets feature replaces per-block editor scripts and styles with shared JavaScript and CSS bundles. Frontend assets are unchanged. Testing measured 91.7% fewer editor assets, a 48.3% reduction in network transfer size, and 62.3% smaller style bundles.

The experiment is disabled by default, and stores can opt in to test it from WooCommerce -> Settings -> Advanced -> Features -> Experimental features. When enabled, WooCommerce blocks use the wc-block-library handle instead of individual block handles, editor styles consolidate under wc-block-library-style, and legacy handles stay registered as placeholders that emit a deprecation warning when enqueued.

PR: #65396

Internal storage for a product video gallery is behind a feature flag as the first step toward product gallery videos; this can be enabled through WooCommerce > Settings > Advanced > Features > Product gallery videos (Beta).

Developer advisories and compatibility work

is_rest_api_request() now detects ?rest_route=

PR: #66816

is_rest_api_request() previously detected REST requests only through pretty-permalink paths under /wp-json/. It now treats a non-empty rest_route query parameter as a REST request.

Other compatibility notes

  • ProductGalleryUtils::get_product_gallery_image_count() is deprecated and restored as a shim that emits a deprecation notice pointing to get_product_gallery_media_count(): #66550.
  • The quantity stepper’s DOM order now matches its visual order, fixing WCAG 1.3.2 and 2.4.3. Themes with CSS keyed to the old DOM order should re-test: #66670.
  • WC_Order_Item_Product::set_product() now resets variation_id, and partial REST order updates preserve variation IDs when product_id is unchanged. An explicit variation_id: 0 still demotes to parent: #66734, #67343.
  • search_products() now wraps its OR-group disjunction in parentheses, so include, exclude, status, and type clauses apply to all groups. Result sets change: #67420.
  • A new GET /wc-analytics/activity-panel/counts collapses three endpoints previously called by two components each, turning six requests per admin page load into one: #66276.
  • Analytics page output no longer carries request-derived properties, so cached pages cannot emit another visitor’s request data: #67003.
  • @woocommerce/entities no longer exposes internal utilities on window.wc.wcEntities. Those utilities were never intended as a public API: #66978.
  • Currency symbol output changes for MOP (P to MOP$) and ZMW (ZK to K). Existing symbol-override filters continue to work: #66716, #66722.

4 responses to “WooCommerce 11.1: What’s coming for developers”

  1. I’m glad to see WooCommerce finally introducing native support for the right of withdrawal in version 11.1.
    However, I’m quite disappointed with the proposed implementation. As it stands, it is essentially just a withdrawal form, without any real integration into the order lifecycle.
    I would have expected withdrawal requests to be directly linked to the relevant order, manageable from the WooCommerce admin, and for customers to be able to select the specific products or quantities concerned when they only wish to withdraw from part of an order.
    A proper request status workflow and a history visible to merchants would also have added significantly more value to this feature.
    For a native feature arriving several months after the regulation came into effect, it’s disappointing to see such a minimal implementation, especially when free plugins already provide much more comprehensive withdrawal and return workflows.
    The native integration is certainly welcome, but I really hope this first version is only a foundation that will be expanded quickly.

    1. Tom Cafferkey Avatar
      Tom Cafferkey

      Thanks for the constructive feedback. The aim for 11.1 was to cover the essentials for every store by default. Just to clarify that requests aren’t entirely detached from the order. When the submitted order number and billing email match an order, the request is recorded on that order as an order note, so it appears where merchants already work. Requests that don’t match are still accepted and flagged for manual review.

      Where this feature goes next will be driven by feedback and usage. However, we can’t commit to a timeline for improving it right now. So, for a fuller returns workflow today, the solutions you mention are a reasonable route.

  2. Alexandra Avatar
    Alexandra

    Dear Woocommerce,

    I am using WooCommerce on my WordPress site. On my store, only logged-in (registered) users can place orders – guest checkout is completely disabled. Therefore, every order is already tied to a user account at the moment of purchase.

    However, on the /my-account/orders page, my customers now see the following message:

    “Please confirm your email address to find previous orders and link them to your account.”

    This is very confusing and misleading for my customers, because:

    They never placed any orders as guests – they were always logged in.

    All their orders are already correctly associated with their account, so there are no “previous orders” to find or link.

    1. Tom Cafferkey Avatar
      Tom Cafferkey

      Thanks for your feedback Alexandra, and apologies for any confusion caused! I am working on a fix that will hopefully be included within the next release (11.1.0) which should help fix this. If the setting to disable guest checkout is checked, then we will not show this message to users.

Leave a Reply

Your email address will not be published. Required fields are marked *