WooCommerce Shopper Lists Call for Testing in 10.9

Every WooCommerce store I have ever worked on has the same quiet problem: shoppers add things to the cart, then disappear. Sometimes for an hour, sometimes for a week. Then they come back, the cart is empty, and the order never happens. For two decades we have papered over this with third-party wishlist plugins, custom “save for later” sessions, and cookie tricks that break the moment a browser updates.

So when WooCommerce announces that Save for Later and Wishlists are landing in core — not as another plugin, not as a paid extension — that is worth a careful look. The catch is that these features are experimental, off by default, and the team is explicitly asking the community to test them before they cross the line from beta to “merchants can switch this on in production.”

Here is what shipped, what it actually does, and how I would handle it on real client stores this week.

What is actually new

On June 26, 2026, WooCommerce published a call for testing for Shopper Lists on the Developer Blog. The post introduces two experimental features that share a single backend: Save for Later and Wishlists. Both are aimed at logged-in shoppers, both are opt-in, and both require WooCommerce 10.9.1 or newer.

Save for Later adds a “Save for later” link to each line item inside the Cart block. Tapping it moves the item to a dedicated Saved for Later section that renders below the cart, preserving variable product attributes so shoppers do not have to re-pick a size or colour when they come back. Wishlists works the other way around: an “Add to wishlist” control appears inside the Add to Cart with Options block on the product page, and saved products show up under My Account > Wishlist.

Both features are switched on from WooCommerce > Settings > Advanced > Features, using the toggles Save for Later in Cart and Wishlists. Default state is off. Under the hood, they share a common Shopper Lists backend exposed through a new Store API surface at /wc/store/v1/shopper-lists/, plus a shared Interactivity API store. The original feature merge — a 26-commit aggregation called shopper-collections — landed in trunk on May 22, 2026. The Wishlist button was reattached to Add to Cart with Options through a render-time injection PR merged on June 17, 2026, so the button does not get baked into persisted templates and the editor does not throw “invalid block” notices when the feature is disabled.

Two important constraints to understand before you switch anything on. First, this is block-only. Save for Later renders inside the Cart block, not the classic shortcode cart, and not the Mini-cart. Wishlists need the Add to Cart with Options block on the product template. If your store is still on classic Woo templates, none of this works for you yet. Second, this is logged-in-only. Guest carts get nothing, which is consistent with how durable lists work everywhere else (you cannot remember a person you never identified), but it matters for stores that bias hard toward guest checkout.

For context, this lands inside the broader WooCommerce 10.9 release shipped on June 23, 2026, which already brought block-based email editor updates, transactional email logging, color swatches, and variation galleries into core. Shopper Lists is the next building block in that same effort: take the third-party plugin you used to bolt on, and bring it into the block-native cart and checkout flow instead.

Why it matters for WordPress and WooCommerce people

The wishlist plugin market for WooCommerce has always been a mess. There are eight or nine plugins that all do roughly the same thing, each with their own data model, their own shortcodes, their own ideas about how variation IDs should be stored, and none of them speak Store API. Migrating a store from one wishlist plugin to another usually means writing a one-off ETL script and apologising to the client. If your wishlist plugin vendor goes quiet, you inherit the maintenance.

A first-party implementation changes the calculus. The data lives in core tables, the surface is the Store API every modern Woo block already speaks, and the contract is governed by the WooCommerce team rather than a single plugin author. For agencies maintaining ten or twenty Woo stores, that is the kind of consolidation that pays back over years — fewer plugins to patch on Tuesday morning, one API to learn, one data shape to migrate to and then never touch again.

It also closes a real conversion gap. Save for later is the single most-requested feature I get from B2B and high-AOV clients, and “wishlist” is the most-requested from gift-driven categories — jewellery, fashion, home goods. Until now the honest answer was “yes, but pick a plugin and live with it.” Now the honest answer can be “yes, in core, on the block-native checkout you already moved to.”

The block-only and logged-in-only constraints are the load-bearing detail though. If your client store is still classic Woo, this is not for you today. If your client store is heavily guest-checkout, the feature only helps the slice of buyers who log in, which on a typical D2C store is a minority. Pretending otherwise will lead to a disappointed merchant six weeks after launch.

What I would do (or not do) about it

For a production store, I would not switch either toggle on yet. The feature flag is in the experimental section for a reason, the Store API surface can still change, and the WooCommerce team is explicitly asking for feedback through a public GitHub discussion before stabilising the contract. Shipping experimental features into a live store is how you end up rolling back at 11 PM.

What I would do this week, on every Woo project we own, is spin up a staging copy on 10.9.1 and switch both toggles on. Check that your theme’s Cart template uses the Cart block (not the shortcode), that your single-product template uses Add to Cart with Options, and that My Account still renders cleanly with the new Wishlist tab. Test variation tracking — pick a size, save it, come back, confirm the size is still there. Test the kill switch — turn the toggles off and confirm no orphan markup appears in the editor or the front end. That last step is the regression I would worry about most on a real store.

If you already sell a third-party wishlist on the same store, do not flip the new toggles on top of it. Wait for a migration path. If you have written custom save-for-later session logic, this is the right week to read the feature merge PR and decide whether your custom code becomes the official one or quietly retires.

For clients still on classic Woo templates: this is one more reason to plan the migration to block Cart and Checkout. They were made the default in WooCommerce 10.9, the email editor went block-native this cycle, and now shopper lists are block-native too. The classic checkout will keep working, but it is increasingly the place where new features are not.

If you have a store where logged-in buyers matter — B2B, subscription, repeat-purchase D2C, anywhere with a real account flow — Shopper Lists is the most consequential WooCommerce feature this cycle. Test it now, file the bugs you find, and you will get a better shipping version when it stabilises.