Most stores can take the WooCommerce 10.8 update this week. Two of the fixes close real holes, and the query reductions continue work I liked in 10.7. But WordPress 6.9 is now the minimum, and anything that talks to your orders REST API deserves a look before you click the button.
WooCommerce posted the 10.8.0 release notes on the developer blog on May 26, after the release slipped a week. By the numbers it’s a big one, 176 pull requests from 67 contributors, and it runs database updates, which is the part of a release post people tend to skip.
Should you run the WooCommerce 10.8 update now?
The case for waiting a couple of weeks on the WooCommerce 10.8 update is mostly about that database update. Four routines run. One backfills sync metadata onto existing block email posts, one creates the Review Order page used by the new review email, one restores the scheduled analytics import preference that was lost when its option was renamed back in 10.5.0, and one modifies the meta_key_value index on the wc_orders_meta table. That last one went back and forth during the cycle. An earlier change slimmed the index to track only meta_key, and a follow-up restored meta_value after a performance regression in order meta lookups. On a store with a large orders table I’d run the update off peak and stay on the page until the updater finishes.
The case for updating now is easier to argue. Unauthenticated access to guest order fulfillments through the REST API is fixed (#64130), and the Store API products endpoint no longer lets arbitrary product IDs in its related parameter bloat your options table with transients (#63846). Merchants won’t notice either fix, but I wouldn’t leave a store without them for long.
Then there’s the performance list. New indexes on wc_orders for transaction ID lookups and on wc_reserved_stock for stock reservation during sales peaks, cache priming for product archives, the product edit screen, the classic cart, grouped products and the Store API product schema, lazy-loaded coupon _used_by meta so a coupon with thousands of usages stops loading its whole usage history at construction, and a default cap on layered navigation filter caches so wp_options stops growing without bound. On a store with big archives and a heavy coupon history, I’d update for these alone.
Check one thing before you commit. 10.8.0 and 10.8.1 contain a fatal when duplicating posts or pages that include Single Product blocks, from a namespaced call to wc_get_notices() in the hydration service, tracked on GitHub. If your client’s editors duplicate landing pages for a living, look at that issue and the latest patch release before they find it for you.
The API changes that can break integrations
Three REST changes matter in practice. All of them fail quietly, so give them a staging pass before the live update.
- status=any on the orders endpoints no longer returns checkout-draft orders, so a consumer has to request status=checkout-draft explicitly (#63743). An integration that used any as its cheap way to spot abandoned carts will just see fewer rows.
- PUT on wc/v2 and wc/v3 orders now rejects non-shop_order records instead of converting them into orders (#64050). This is the change I’d test first, and I wrote about it separately when the strictness first appeared.
- The V4 products response strips downloads, cost of goods and purchase notes for users without product management capabilities (#63895). Keys tied to a low-privilege user will silently lose fields they may have relied on.
There is also a new product.published webhook topic (#63555), which is handy if you push catalog changes out to a search service or a feed.
GraphQL arrived as a second API surface in this release (#63772), with a settings section under Advanced that toggles a GET endpoint, an engine other code can use, and an internalized webonyx package, presumably so a plugin’s own webonyx dependency doesn’t collide with core’s. My position is to keep building client work on the REST API, because it is documented, stable, and the thing every connector already speaks. GraphQL in core is one release old and starts with a read endpoint, so I’d treat it as a staging experiment until it has a cycle behind it. (I’m not sure yet how it lines up with the Store API’s authenticated shopper flows, and that’s the part I’d watch.)
Before updating, measure how many drafts your store carries, because that’s how many orders your status=any consumers will stop seeing:
wp eval 'echo count( wc_get_orders( array( "status" => array( "checkout-draft" ), "limit" => -1, "return" => "ids" ) ) );'If that prints a large number, something polling your orders endpoint was almost certainly counting drafts without realizing it.
What I’d enable and what I’d leave alone
The Customer Review Request email is the headline feature, and it ships off by default and feature-gated. Enabled, it schedules a message through Action Scheduler a configurable number of days after an order completes, cancels the job if the order is later cancelled, refunded or trashed, and lands the customer on a tokenized, read-only page with an accessible 5-star control. Submissions become verified-buyer reviews, and fully refunded items are excluded. If the store already runs a review reminder plugin that earns its keep, leave the core version off. Two systems sending review mail is worse than one. If it runs nothing, turn the core one on.
The coupon code email block can now generate a unique code per recipient at send time from rules you configure (#64342), which used to be small-plugin territory. Block email posts also carry template sync metadata now, with a one-click reset to the distributed content, and the update backfills that metadata for you. Warn anyone who hand-edited email templates about the reset button, because it discards their edits in one click.
Custom shipping providers (#63879) is the change I’m happiest about, even though nobody will announce it. A settings screen for defining carriers and tracking URL templates, plus order filtering by provider, replaces a lot of the snippet work this job used to need.
If you’re updating today, run wp core version to confirm you’re on 6.9 or newer, run the eval above to count your checkout drafts, then update and let the database update finish before you close the tab. If your store has an orders API integration you’re not sure about, that check is the kind of work I do for clients, so send it over if you want a second pair of eyes.
