If a sale collection returns fewer products while testing WooCommerce 11.3, inspect the combined API filters before restoring the old output. The update corrects how on_sale works with include and exclude. Products that previously slipped through a conflicting combination may now correctly disappear.
As of October 27, 2026, 11.3 is beta software. Reproduce this on staging and keep the current production version unchanged until the store's release process approves an upgrade.
Establish what the collection promises
Ask whoever owns the page whether it should show all nominated products, only nominated sale products, or all sale products except a blocked set. These are different contracts. A heading such as Staff picks does not necessarily mean every item must be on sale; a Sale picks heading usually does.
Capture the request URL from the component that supplies the products. Check the actual on_sale, include and exclude values after the frontend has assembled them. A visual editor's settings can differ from the request emitted by a cached widget or custom integration.
The upstream filter correction explains why the old combinations could return unexpected products. The useful test is whether the new result satisfies the intended filters, not whether it matches an old screenshot exactly.
Build a three-product fixture
Use three published, visible staging products with known IDs. In this example, 201 is regular price, while 202 and 203 are currently on sale. These numbers are synthetic; replace them with your own staging IDs. Keep stock, visibility, publication status and sale scheduling consistent so they do not introduce a second variable.
| Request combination |
Expected IDs in this fixture |
| on_sale=true with include=201,202 |
202 |
| on_sale=false with include=201,202 |
201 |
| on_sale=true with exclude=202 |
203 |
| on_sale=false with exclude=201 |
No matching product |
The last row is important. An empty result should not silently become an unrestricted collection. The UI should show an intentional empty state, not unrelated stock disguised as a successful filter.
Synthetic product set: 201 is regular price, 202 and 203 are on sale. The include and sale conditions must both match; exclude removes matching IDs.
Check the public Store API response
On your authorized staging host, request the actual product IDs through the same API route the storefront uses. This read-only example uses the Store API, not an authenticated administrative API:
curl -sS --max-time 15 'https://staging.example.com/wp-json/wc/store/v1/products?on_sale=true&include=201,202'
Read the returned IDs and sale state. An HTTP 200 only says the request completed; it does not confirm the collection is correct. Keep the full relevant response in a restricted test record, and summarize only product IDs and filter inputs in a public issue.
Repeat the cases against the API version your integration actually uses. If it also requests variations, use variation IDs and the correct parent route rather than substituting parent IDs into a variation test. Do not expose REST API secrets in a URL or screenshot.
Trace differences between API and page
If the raw response is correct but the page differs, inspect the component's local filtering, cached JSON and request cache key. Make sure two requests with different query parameters cannot reuse the same cached result. Purge only the relevant cached page or request after confirming the origin response.
If both response and page are wrong, compare requests with and without the custom extension that alters product queries on staging. Keep all other fixture conditions unchanged. A disappearing product may instead be hidden from the catalog or no longer within its sale dates; the catalog visibility guide covers that separate investigation.
Do not remove on_sale merely to bring the old count back. That changes the business rule. If the intended collection is a manually curated list regardless of price, document that decision and change both the request and page wording consistently.
Approve membership before measuring speed
Record the expected and returned ID sets for each case, the exact build, endpoint, theme and query-altering plugins. Then check pagination and the empty-state message. A result count that looks plausible can still contain the wrong products.
Only after the contents are correct should you use the product-filter performance workflow to investigate speed. A faster incorrect query is not an improvement.
The 11.3 release advisory lists affected endpoint families. Recheck the final release notes before deployment. HandL WP troubleshooting can help isolate the request builder, cache boundary and extension callback when those layers disagree.
Sources checked October 27, 2026. Procedures and synthetic diagrams are explanatory, not claims of customer testing.
For a correct sale collection whose badges still look wrong, check the displayed discount independently of product membership: WooCommerce 11.3 Sale Badges: Test Each Variation, Not Just the Parent.