Catalogue filters Pro

Place the filter shortcode on your shop page, a category page, or beside a product table:

[storemaster_filters facets="cat,attr:colour,price,stock,sale"]

What can be filtered

Category, tag, any product attribute, price, stock status, sale status, product type and rating. Attribute facets are named attr: followed by the attribute slug.

Filters are a URL

Every selection lives in the query string. That means a filtered view can be bookmarked, shared, linked to from a campaign, and walked backwards and forwards with the browser buttons — with no JavaScript involved at all.

It also means the back button does what a shopper expects, which is the part scripted filters most often get wrong.

Counts tell the truth

The number beside each option answers "how many if I also tick this", given everything else currently selected — not "how many exist". A global count cheerfully offers you a filter that leads to an empty page.

If a shopper cannot see certain products, those products are not in the counts either. A count computed over things you are not allowed to open is both wrong and a disclosure.

Ticking two things

Two values of the same filter are OR — ticking blue and red shows both. Values across different filters are AND — blue and large. That is what ticking two colours means to a shopper, and the other way round returns nothing and looks broken.

The index

Filters read the catalogue index, which is what keeps a large shop fast. Build it under StoreMaster → Catalogue index.

Rebuilds happen in the background, into a new version, and swap in atomically when they finish. Shoppers see the previous index until the moment the new one is complete — never a half-built one, and never an empty shop because a rebuild was running.

If no index has been built, the filter list renders nothing rather than guessing, and a health check tells you why. Product search and tables keep working from ordinary WooCommerce queries: an unavailable index means fewer features, never wrong results.