If a custom product filter stops matching its option counts in WooCommerce 11.3, inspect the collection's query contract before rebuilding the product catalog. Local Product Collections with filtering enabled now share filtering infrastructure with Product Filters. Extensions that modify generated conditions need a targeted compatibility check.
The 11.3 release is still in testing as of October 29, 2026. Run this procedure on staging with an exact build recorded, not against active customer traffic.
Establish whether the collection is in scope
Open the affected template and identify the Product Collection block. Record whether it inherits the template query and whether filtering is enabled. Compare a local collection with an ordinary catalog archive. A failure isolated to one configuration is more useful than a report that every product query is broken.
The developer advisory directs extensions handling price, stock, attribute and taxonomy filters to modify query arguments instead of relying on generated meta_query or tax_query clauses. That does not mean removing unrelated custom conditions or treating rating filters as the same migration.
Use products with an unambiguous expected result
Create four synthetic products: a low-priced in-stock red item, a high-priced in-stock red item, a low-priced out-of-stock blue item and a high-priced in-stock blue item. Assign a simple test category to all four. Write down their IDs and exact prices.
Before filtering, confirm which items the collection is meant to include. Account for the store's configured out-of-stock visibility. A filter cannot return a product already excluded by the collection's baseline or catalog visibility settings.
Use a price ceiling between the two price points. Combine it with color and stock filters one at a time. Record expected IDs, returned IDs and the option counts shown alongside each choice. Test the actual identifiers rather than relying on similarly named product cards.
Inspect the extension's modification point
Search custom code for query_loop_block_query_vars and review what the callback changes. Save a before-and-after representation of the relevant query arguments on staging. Do not dump whole request objects or customer data into public logs.
If the callback edits generated price clauses, ask the maintainer to adapt it to the supported argument, such as max_price, within the affected block's scope. A callback applied to every query on the site can also alter ordinary posts or unrelated collections. Preserve the conditions that identify the intended block.
Do not copy a replacement SQL fragment from a different WooCommerce version. The point is to express the filtering intent at the supported boundary, not to recreate an internal implementation whose shape is changing.
A proposed collection-filter test moves from a known baseline to combined filters and navigation restoration. Synthetic explanatory visual.
Test results and counts as a pair
The implementation's test guidance specifically covers local filterable collections and attribute behavior with the lookup table disabled. Include that configuration only on an isolated test copy if it matches the supported scenarios you need. Do not toggle production indexing or lookup settings merely to gather evidence.
After each filter, inspect the rendered products and the available option counts. Clear one condition while leaving another active. Navigate to the next page, reload the resulting URL and use browser Back. The same chosen filters should describe the same product population after the state settles.
If the URL itself loses or renames taxonomy choices, use the separate filter-parameter guide. A parameter-mapping problem and a custom query-clause problem can look similar but require different changes.
Approve the smallest compatibility repair
Compare the fixture with and without the custom callback, keeping the theme, product data and beta build fixed. Confirm that the callback's intended business condition still holds after the repair. Removing the entire callback may restore visible products while accidentally removing a required catalog restriction.
Use the product-filter performance guide only after correctness is established. Record performance separately from membership. For a result/count mismatch that survives the control case, request a focused WooCommerce filter investigation with the four-product fixture and redacted argument comparison.
Reference and review date
Primary technical reference. Sources checked October 29, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.