Release v6.42.0
Super Speedy Filters v6.42.0
What's new in v6.42.0
Super Speedy Filters v6.42.0 was released on . Some things could not be fully optimised by Scalability Pro alone which is why Super Speedy Filters was created. See the full changelog below and compare with the complete version history.
Release details
Released
2.5 MB
File available
Changelog
Other
- Filters can now be shown only for specific categories, not just "when any category is selected". Previously the "hide until other filters selected" option could only ask whether a taxonomy was being filtered at all, so on a store with different attributes per category, picking any category showed every filter. You can now write conditions like product_cat=televisions, or product_cat=televisions|audio for several. Slugs, names and term IDs all work
- Category conditions understand your category tree. A filter set to show for Televisions also shows in its subcategories, so you never have to list every child category. The reverse deliberately does not apply - a filter scoped to a subcategory stays out of the parent
- Auto Configure now sets those conditions for you: each filter is restricted to the categories where it actually has results, so a screen-size filter on a store that only sells televisions and audio is created with the condition product_cat=televisions|audio, and clothing pages stop paying for a filter that could only ever render as nothing. Filters with results across most of the store stay store-wide, colour, size and brand are never restricted because shoppers expect them everywhere, and every decision is shown with its evidence so you can override it
- If the lookup tables have not been built yet, Auto Configure leaves every filter store-wide and says so, rather than guessing from missing data
- Swatch colours now live on the term itself, not only inside each filter widget. Previously a colour was stored per-widget against the term's NAME, so renaming a term made its swatch go blank, two filters showing the same attribute each needed the whole palette entered separately, and nothing could set a colour programmatically. There is now a Swatch colour field on the Add/Edit Term screen, beside the existing Thumbnail field, and a colour set there is shared by every filter showing that taxonomy
- Your existing widget colours are copied onto the terms automatically after updating, but only where every filter agrees on the colour, so nothing you can see changes. Colours that differ between filters, or whose term has since been renamed, are left exactly as they are and listed in a one-time notice for you to set on the term screen. The migration never overwrites a colour already on a term and never removes the old widget values, and wp ssf migrate-colours re-runs it (with --dry-run) whenever you want
- Filter colours can still be set on the widget as before, and the two coexist: the term's colour wins, the widget's palette fills in for terms without one, and the ssf_change_color_hex filter still overrides both
- Because the colour is now resolved on the server, colour swatches no longer need their palette sent to the browser as JavaScript. That is what makes colour filters work properly as Gutenberg blocks, where the old JavaScript round trip caused problems
- The agent never invents your filter configuration. Every decision about which filters to create and how each should look stays in the plugin, and the abilities simply trigger it and report back, so you get the same result whether you press the button or ask an assistant
- Auto Configure over MCP refuses to create more than 40 filters at once unless you explicitly allow it, and undoing a run needs confirmation, so an assistant cannot rewrite a large store's filters by accident
- Filters on pages your own SEO rules mark as not-for-indexing now wait for a real visitor before doing any work. Bots endlessly replaying deep filter URLs they harvested get the page shell at a fraction of the cost, because the filter panels only load on the first mouse movement, scroll, tap or key press - and every visitor, human or bot, receives identical HTML, so there is nothing for search engines to object to. Uses your existing SEO and Indexing settings; nothing new to configure
- Filter URLs pointing at terms that no longer exist now answer 410 Gone instead of 404, wh
Added
- a Match setting beside the condition list, so several conditions can require all of them or any one of them. All existing filters keep their current behaviour, which requires all of them
- AI agent control. Super Speedy Filters now exposes eleven abilities through the WordPress Abilities API, so an assistant like Claude can inspect and configure your filters for you: describe what the plugin can do, list your filters and taxonomies, plan a filter set, run Auto Configure, undo it, set swatch colours and filter icons, move colours onto terms, and rebuild the lookup tables after an import
- two capabilities, Manage filters and Apply filters, plus a Filter Manager role, so an assistant can be given its own account with only those rights instead of a full administrator login. Existing administrators get both automatically
Removed
- the old user-agent bot detection. It could only recognise honest bots - and then showed them different filters than real users saw, which is exactly what search engines penalise - while disguised scrapers sailed past it. The new behaviour above treats every user agent identically
Compatibility
- Requires WordPress
- 6.2
- Tested up to
- 7.0
- Requires PHP
- 7.0
Verified safe
Super Speedy Filters v6.42.0 scanned clean with no security threats detected.
View full scan report