WooCommerce 11.2: What Changes on October 6 and What to Test Before You Update

WooCommerce 11.2 is scheduled for the week of October 6, 2026, and as of October 4 it is still in beta. Most of what is in it is small and sensible. A few items are not, and one of them can change the numbers in your reports without throwing a single error.

This guide covers what the 11.2 beta notes and the related developer advisories say, which changes can affect a live store, and how to test them on a staging copy before you update. Everything here comes from WooCommerce's own developer blog, its GitHub repository, and the WordPress.org plugin page. Where a detail could still change before the final release, it is marked.

TL;DR

• WooCommerce 11.2 is planned for the week of October 6, 2026. The latest stable version today is 11.1.2. Do not run the beta on a live store.
• The change most likely to catch you out: date filters in wc_get_orders() and wc_get_products() now read a date like 2026-07-20 as a day in the store's timezone. Reports, exports and scheduled jobs that filter by date can return different results with no error.
• Order queries are affected only on stores still keeping orders in the WordPress posts tables. Stores on High-Performance Order Storage (HPOS) see the change for products only.
• The abandoned cart recovery and Agentic Checkout experiments are removed. The experimental Dual API moves out of core into a separate plugin.
• Test on staging: run the same date query on 11.1.2 and 11.2, then walk through checkout, coupons, imports and any custom code that touches the changed hooks.

When is WooCommerce 11.2 released, and what is stable right now?

The 11.2 pre-release notes, published September 21, 2026, give the release week as October 6. WooCommerce's release tracking issue on GitHub lists beta 1 on September 21, beta 2 on September 28, a first release candidate on October 5, and the stable release on October 6. Beta 2 is already published as a pre-release on GitHub.

The current stable version is 11.1.2, released September 22. Its WordPress.org page lists WordPress 7.0 or higher and PHP 7.4 or higher. The 11.2 notes do not state their own minimum versions, so check the readme of the final release before you assume they match.

Release dates move. The 11.1 release was postponed by a day on the day it was due, and WooCommerce announced that in a developer advisory. Treat October 6 as the plan, not a promise, and read the final release notes when they appear. Some details below may be reworded or added by then, because the pre-release notes are written against the first beta.

Why can a WooCommerce report change without any error in 11.2?

This is the item to understand first. In 11.2, wc_get_orders() and wc_get_products() read a date string such as 2026-07-20 as a day in the store's timezone. Before, the day boundaries were built in a way that ignored the store timezone, so a filter for one day could return a window that was mostly the wrong day.

Nothing throws an error. A nightly export, a reconciliation script, a custom dashboard widget or an accounting sync that passes a date range will simply return a different set of rows after the update.

Which queries are affected?

The pull request behind the change, which WooCommerce's notes link to, names the specific query variables. These are the ones it lists:

The release notes put the scope in one sentence: product queries change on every store, and order queries change only on stores still keeping orders as posts. HPOS has been the default for new stores since WooCommerce 8.2 in October 2023, so many stores will see no change for orders. Older stores that never switched will.

One caution. The pull request lists date_on_sale_from and date_on_sale_to for products. I could not confirm from the sources whether other product date parameters are affected, so if your code filters products by any other date, test it rather than assume.

How big is the shift?

The pull request author published a table of how much of the requested day the old window actually covered, for a query on a July date. These figures are the author's own analysis, not an independent measurement:

The pattern: stores east of UTC, including most of Europe, were furthest off. A store with a UTC offset of zero on the queried date is mostly unaffected, but that depends on the date. A London store is at UTC+0 in winter and UTC+1 in summer, so the same store can be correct in January and wrong in July.

Three smaller behavior changes in the same fix

The pull request lists a few more effects worth knowing:

• Ranges now include the whole last day. A range such as 2026-07-19...2026-07-20 used to collapse its final day down to that day's first second. It now covers the full day, which the author flags as the change a store is most likely to notice, because a range query returns an extra day of data.
• A date with a time in it names the day of that instant in UTC. A value like 2026-07-20 22:00:00 on a store at UTC-4 used to name the 21st and now names the 20th, matching how HPOS already worked.
• Nothing is written or migrated. The change alters query results only, so the stored data is untouched.

The double-correction trap

If your code worked around the old behavior by shifting its own date window so daily totals lined up, it will now correct twice and report the wrong day. The pull request author says there is no signal when this happens and that they could not list which integrations do it. Search your own code and any custom reporting plugin for hand-built offsets before the update, not after.

How to check your store

First, find out how your orders are stored. In wp-admin, go to WooCommerce > Settings > Advanced > Features and look at the order data storage setting. Then compare results on two copies of the site, one on 11.1.2 and one on 11.2. This script prints counts for a day that has real orders. Replace the example date with one from your own data.

<?php
// compare-dates.php
// Run with: wp eval-file compare-dates.php
$day = '2026-09-15'; // use a day that has real orders and sales

foreach ( array( 'date_paid', 'date_completed' ) as $key ) {
	$ids = wc_get_orders(
		array(
			$key     => $day,
			'limit'  => -1,
			'return' => 'ids',
		)
	);
	echo $key . ': ' . count( $ids ) . " orders\n";
}

$ids = wc_get_products(
	array(
		'date_on_sale_from' => $day,
		'limit'             => -1,
		'return'            => 'ids',
	)
);
echo 'date_on_sale_from: ' . count( $ids ) . " products\n";

Run it on both copies and keep the two outputs side by side. If the counts match, your store is probably not affected for those queries. If they differ, find which report or job uses that filter and decide which number is the right one before you update production.

You can also check your timezone setting from the command line:

wp option get timezone_string

If that returns an empty string, your site may be using a manual UTC offset instead of a named timezone. Check Settings > General in wp-admin.

What is removed in WooCommerce 11.2?

Three experimental features leave core. All three were off by default, so most stores never used them, but removal is still removal.

The experimental Dual API becomes a plugin

WooCommerce 10.9 introduced an experimental Dual API, a code-first setup that generates GraphQL endpoints from PHP classes. In 11.2 the engine moves out of core into a separate plugin called WooCommerce Dual API. Because it was always behind a feature flag, the change only affects developers who opted in and built on it.

The details that matter if you are one of them:

• The built-in proof-of-concept API for products and coupons, present in 10.9 through 11.1, is removed. The new plugin does not bring those endpoints back.
• The feature flag is gone. Installing and activating the plugin is what turns the engine on.
• The plugin requires WooCommerce 11.2 or newer and PHP 8.1 or newer. An extension that depends on it should declare Requires Plugins: woocommerce, woocommerce-dual-api in its plugin header.
• WooCommerce says the Dual API stays experimental, that anything under the Automattic\WooCommerce\Api namespace can change in incompatible ways in any release, and that it should not be used in production extensions.

That last point is the one to take seriously. If a client's store depends on an extension built on this engine, ask the extension author what their plan is.

Abandoned cart recovery and the Agentic Checkout API are gone

The experimental abandoned cart recovery feature and the experimental Agentic Checkout API are both removed. The wc/agentic/v1 routes go with no replacement endpoint. The 11.2 database update also cancels any queued recovery actions and drops the wc_email_unsubscribes table.

The pre-release notes do not say whether that database step can be undone. Treat it as one-way. If you ever turned these experiments on and you care about anything in that table, take a full backup first and check the table before you update.

Which developer changes could break custom code?

WooCommerce lists many developer advisories in the 11.2 notes. Most are narrow. This table covers the ones likely to matter, with what to search for in your own code.

The notes also list a few changes to report totals query hooks and legacy product widget ordering. If you maintain custom reporting, read the full advisory list on the developer blog rather than relying on this summary.

To find affected code over SSH, run these from your WordPress root. Each one only lists matching lines, so you can review them before changing anything.

grep -rn "wc_get_orders\|wc_get_products" --include=*.php wp-content/plugins wp-content/mu-plugins wp-content/themes | grep -i date
grep -rn "register_wp_admin_settings" --include=*.php wp-content
grep -rn "woocommerce_quantity_input_min_admin" --include=*.php wp-content
grep -rn "%url%" --include=*.php --include=*.js wp-content/themes wp-content/plugins

You can also list every active plugin and its version to build the checklist of extensions to check against 11.2:

wp plugin list --status=active --fields=name,version

What changes for the Store API and the Cart and Checkout blocks?

If you run a headless storefront, a custom checkout, or code that talks to the Store API, three changes are worth reading closely.

A new filter for cart quantity limits

WooCommerce 11.2 adds woocommerce_store_api_cart_item_quantity_validation. The older cart had woocommerce_update_cart_validation for rejecting a quantity change, but the Cart and Checkout blocks had no equivalent. Anyone who tried to cap quantities on the block cart with the old filter found it never ran.

The new filter runs after WooCommerce's own minimum, maximum and multiple-of checks, when a quantity is updated or a product already in the cart is added again. It does not run on the first add of a product. For that, WooCommerce points to the woocommerce_store_api_validate_add_to_cart action.

add_filter(
	'woocommerce_store_api_cart_item_quantity_validation',
	function ( $valid, $quantity, $product, $cart_item ) {
		if ( $quantity > 5 ) {
			return new WP_Error(
				'quantity_limit',
				sprintf( 'You can order up to 5 of "%s".', $product->get_name() )
			);
		}
		return $valid;
	},
	10,
	4
);

Two traps come straight from the advisory. Only a WP_Error return rejects the change. Any other value, including false, is ignored and the quantity is accepted. And the old pattern of adding a notice with wc_add_notice() and returning false does not carry over, so a callback copied unchanged from woocommerce_update_cart_validation will accept every change. Keep your old callback too, since it still covers the shortcode cart.

Rate limits and cart-session failures

The Store API now returns HTTP 429 instead of 400 when requests exceed the rate limit. A client that treats every 400 as a validation error and every other code as something else may handle this badly. Check how your front end reacts to a 429.

A failure to load the cart session now returns a 500 with no Cart-Token or Cart-Hash headers. WooCommerce says clients should treat missing headers as an unavailable cart, not as a new cart.

Layout changes in the blocks

The Cart and Checkout blocks now use a fixed 360px order summary column, and the two-column breakpoint moves from 700px to 920px of container width. Custom CSS written against a percentage width or a 700px media query may misalign, so open your checkout on a few screen widths on staging.

What is new for store owners in 11.2?

Not everything in the release is a risk. These are the additions the pre-release notes highlight:

• Withdrawal request emails. WooCommerce adds configurable emails that acknowledge a customer's order withdrawal request and notify the merchant. You manage both under WooCommerce > Settings > Emails, including recipients, extra content, previews, and whether each email is on.
• Product CSV importer matching. With "Update existing products" on, the importer now matches by GTIN, UPC, EAN or ISBN when a row has no ID or SKU. The match order is ID, then SKU, then the global unique ID. A non-blank identifier that matches nothing skips the row instead of creating a product, and a match with a different product type is refused, so an update cannot silently change a product's type.
• Narrower import cleanup. Import cleanup no longer runs site-wide deletes of orphaned variations, post meta and term relationships. It now removes only the placeholder products that the import itself created.
• Date fields in additional checkout fields. Developers can add date fields to the Checkout block, such as a preferred delivery date, with limits like "from tomorrow through the next 30 days". They use the browser's native date picker.
• More block styling options. Product Image gets border styles, Product Quantity gets border, shadow, radius and color options, Product Filters can be sticky, and Chips get typography and spacing options.

The CSV importer change is the one to try on staging if you update catalogs from supplier files. Run a small test file with a mix of rows that have IDs, SKUs and barcodes only, and check which rows update and which are skipped.

What about the product hook changes announced earlier?

WooCommerce announced separate changes to product save and product reordering hooks in a developer advisory on August 25, aimed at faster saves and reordering on large catalogs. MagicWP's earlier article, WooCommerce 11.1 and 11.2: What's New and What Might Break, covers those in detail, including the set_object_terms and ordering hooks, so they are not repeated here. If your code touches product saves or drag-and-drop product ordering, read that article before you test.

Does WooCommerce 11.2 change the PHP requirement?

Not yet, as far as the sources show. A developer advisory published September 29 says WooCommerce 11.6, planned for February 2027, will require PHP 8.1 or newer. WooCommerce 11.3 will show a dismissible admin notice on stores running PHP 7.4 or 8.0, and WooCommerce says 11.3 keeps working on those versions. Stores on older PHP can keep updating through 11.5.

This differs from an earlier proposal, published September 8, that targeted 11.5 and January 2027. The September 29 advisory is the later one and moves the date to 11.6. WooCommerce also says PHP 8.3 or newer is its current recommendation.

The one place PHP 8.1 already matters in 11.2 is the Dual API plugin, which needs it. If your host still runs an older version, plan the upgrade now. MagicWP's guide to which PHP version to run for WordPress in 2026 covers how to choose.

How should you test WooCommerce 11.2 on staging?

Do not install the beta on a live store. WooCommerce's own beta testing guide says running beta versions on production is not a good idea unless you can anticipate changes and failures. Use a copy, and wait for the stable release for production.

1. Take a backup first. Make a fresh on-demand backup before any change. MagicWP also keeps daily off-site backups with one-click restore, described in the backups documentation.

2. Create a staging copy. A full copy of the live site is what you want, with real orders and products so date queries have data to return. MagicWP's staging feature is covered in Staging Sites and Smoother Migrations.

3. Record a baseline on 11.1.2. Run the date comparison script above and save the output. Export one report you rely on, such as a daily sales total, so you have numbers to compare.

4. Update staging. To try the beta early, install the WooCommerce Beta Tester plugin on the staging copy only, switch to the beta channel, and update. After October 6, update to the stable release instead:

   terminal

   wp plugin update woocommerce
   wp plugin get woocommerce --field=version

5. Rerun the script and the report. Compare against your baseline. Any difference should match the date filter changes above, and you should be able to explain it.

6. Walk the critical paths. Check out as a guest and as a logged-in customer. Change a quantity in the Cart block. Apply two coupons if you use sequential discounts. Edit an order in the admin. Run a small CSV import. Check any webhook consumers.

7. Check front-end layout. Look at the Cart and Checkout pages at phone, tablet and desktop widths, and at a classic theme's product archive pagination if you use one.

8. Read the logs. Check the PHP error log and the WooCommerce logs under WooCommerce > Status > Logs for new warnings, especially deprecation notices from extensions.

9. Choose your production window. Update during a quiet period, and avoid the days when you close the month or run reconciliation, since the date filter change affects exactly that kind of work.

If something breaks on staging, you have lost nothing. If something breaks on production after an update, restore from the backup you took in step 1 and fix it on staging before trying again.

Frequently Asked Questions

When is WooCommerce 11.2 released?

WooCommerce 11.2 is planned for the week of October 6, 2026. The pre-release notes give that as the release week, and WooCommerce's release tracking issue lists October 5 for the first release candidate and October 6 for stable. Dates can slip, as 11.1 did by a day, so check the developer blog on the day. Until then, the latest stable version is 11.1.2.

Will the date filter change break my reports?

It might change them, which is different from breaking them. Queries that filter by date_paid or date_completed on stores keeping orders in the WordPress posts tables, and product queries that filter by sale dates, now use the store timezone. Stores on HPOS are not affected for orders. Run the same query on 11.1.2 and 11.2 on a staging copy and compare the counts before you update production.

Do I need PHP 8.1 for WooCommerce 11.2?

The sources I checked do not list a new PHP minimum for 11.2 itself, and 11.1.2 lists PHP 7.4 or higher. The PHP 8.1 requirement is planned for WooCommerce 11.6, targeted for February 2027, with a notice arriving in 11.3. The Dual API plugin does need PHP 8.1 today. Confirm the final 11.2 requirements in its readme.

Should I install the 11.2 beta on my live store?

No. WooCommerce's beta testing guide says to test responsibly and not to run beta versions on production unless you have experience and can anticipate changes and failures. Install the Beta Tester plugin on a staging copy, or wait for the stable release on or after October 6. A beta on a live checkout puts real orders at risk for no benefit.

Will I lose data when abandoned cart recovery is removed?

Possibly, if you used it. The 11.2 database update cancels queued recovery actions and drops the wc_email_unsubscribes table. The notes do not say whether that can be reversed, so treat it as permanent. If you turned this experiment on, back up the site and check that table first. If you never enabled it, which is the default, nothing changes for you.

How do I limit cart quantities in the Cart block?

Use the new woocommerce_store_api_cart_item_quantity_validation filter in 11.2 and return a WP_Error for quantities you want to reject. Returning false or adding a notice with wc_add_notice() does not work. The filter runs on quantity updates and repeat adds, not on a product's first add, which needs the woocommerce_store_api_validate_add_to_cart action instead.

Do I need to change anything if I have no custom code?

Probably very little. Most of the breaking changes affect custom code, extensions and integrations. Still check your active extensions for 11.2 compatibility notes, run your normal checkout on staging, and look at your Cart and Checkout layout, since the order summary column width changed. Stores with date-based reports or exports should do the date comparison no matter what.

Conclusion

WooCommerce 11.2 is mostly a tidy release, and the one change to take seriously is the date filter fix. It makes queries correct, but a correct query can still change a number you have been relying on, and it does so quietly. Run the same query on two copies of your store and you will know in a few minutes whether it touches you.

The rest is a checklist: check your custom code against the advisory table, remove any dependence on the removed experiments, and look at your block layouts. If you want a place to rehearse the update, MagicWP's WooCommerce hosting includes one-click staging and on-demand backups, so testing WooCommerce 11.2 before October 6 costs a copy of your store rather than a risk to your live one.

Next steps

• Read the official WooCommerce 11.2.0 pre-release notes and watch the developer blog for the final release notes.
• Read the advisory on the new Store API cart quantity filter if you build custom cart rules.
• Read the post on the Dual API moving to a plugin if any extension you use is built on it.
• Read the advisory on the PHP 8.1 requirement planned for WooCommerce 11.6.
• Review MagicWP's guide to backing up and restoring a WordPress site.