10 versions
Super Speedy Filters history.
Every release of Super Speedy Filters is archived here with its changelog, file size, and security scan result. Use the archive to roll back to a stable release or audit what changed between updates.
8 of 10 releases scanned clean
v6.52.39Latest
August 26, 20262.5 MBScanned
August 4, 20261.8 MBScanned
* Pretty URLs can no longer be switched on when Permalinks are set to Plain, with a tooltip explaining why. The add-on works by adding rewrite rules, which Plain permalinks do not run, so it had no effect on those sites. If it is already on you can still switch it off.
* WPML and Polylang: filter widgets now list only the terms belonging to the language being viewed, so each language shows its own facets and its own counts
* WPML and Polylang: SEO overrides can now be set per language, using the new Language selector on the override and the language shown against each one in the list
* An SEO override set to a language matches the page in either WPML URL format, whether the language is a directory such as `/fr/` or a separate domain
* The SEO title and meta description wording - prefix, suffix, separator and the per-taxonomy connectors - can now be translated in WPML String Translation or Polylang Strings, under the *Super Speedy Filters* domain
* Filter links resolve to the correct term where two languages share a term slug, which happens most often when you use a different domain per language
* Widget caching now varies by language under Polylang as well as WPML
* Taxonomy archives return their products while the performance table is still being built, rather than only after `wp ssf rebuild` has run
* Filters created by Auto Configure now respect the other filters on the page, so clicking one keeps the category you are already in
* Filter widgets no longer log `Undefined array key "resetcategory"` notices
* Tested up to WordPress 7.0
* Auto-configure no longer removes your existing filters before it knows the new ones can be written - if anything goes wrong, your filters are put back exactly as they were
* Undoing an auto-configure now keeps anything you added inside the filters layout yourself, instead of replacing the whole block with just the product grid
* Undo only removes the filters that auto-configure created: a filter widget or filter block you added by hand is left alone, even if it sits in a slot a removed widget used to occupy
* Auto-configure and undo no longer strip a level of escaping from the rest of the template, which could leave other blocks (notably ones carrying a font family) rendering with their default settings
* Auto-configure survives a corrupted internal record instead of stopping half way, which previously left filters on the site with no way to undo them and added a second full set on the next run
* Re-running auto-configure keeps the choices you made yourself rather than resetting them to the automatic ones
* Setting a swatch colour by term now matches the term slug first, so a term whose slug is a number gets the colour instead of an unrelated term with that ID
* Auto-configure is now flagged to AI assistants as a replacing operation, so they ask before running it
July 29, 20262.5 MBScanned
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
July 23, 20262.3 MBScanned
Fixed
- "Show but delay execution" filters on search results showing an empty filter after loading. The REST endpoint was returning the built filter correctly, but the JavaScript that swaps it into the page was looking for a CSS class the built response only carries in some widget configurations, so for plain configurations the placeholder was removed without the options being inserted. The swap now targets the content element the endpoint always returns, and the freshly loaded filter is re-initialised (selected counts, per-page term lists and crawler-safe links) after insertion. Thanks to @rexhavoc for tracing this and sending in the diagnosis
- a delayed filter getting permanently stuck in its loading state if the load request failed - it can now be retried by interacting with the filter again
- a fatal error when clearing the filter cache on sites where the transient widget cache constant is not defined
July 7, 20262.2 MBScanned
Fixed
- the "Show but delay execution" filter still not loading on search results on some sites (typically HTTPS/staging). The lazy-load request used an absolute REST URL from `rest_url()`, which could come back as `http://` or a different host and be blocked by the browser before any request was sent, so nothing showed in the network tab. It now uses a root-relative URL that always matches the page's own scheme and host.
v6.34.1Unavailable
June 15, 20262.2 MBScanned
Improved
- use of to HTML comments instead for VERBOSE DEBUG mode.
v6.30Unavailable
March 3, 20262.1 MBScanned
Improved
- integration between rules based SEO overrides and Exact match SEO overrides so that archive title will be overridden correctly and only written once to the page
Other
- Implemented mini-refactor of SEO handler (rules-based) and SEO Overrides (exact match based)
v6.29Unavailable
February 28, 20262.1 MBScanned
Improved
- SEO override handler
Other
- Restored SEO override configs
Fixed
- duplicate SEO h1 override
- issue with exact match override causing blank titles on non-overridden pages
v6.28Unavailable
December 24, 20252.1 MBUnknown
Added
- full namespacing for plugin update checker to prevent conflicts with 3rd party plugins
v6.27Unavailable
December 24, 2025854.0 KBUnknown
Removed
- some dead code
Improved
- bad-bot + ajax handling further to improve page speed and reduce caching
Other
- Renamed debounce function and related objects to be prefixed with ssf_ to avoid conflicts with other JS plugins
Why archive
Sometimes the latest release isn't the one you need. The archive lets you pin Super Speedy Filters to a known-good version, or roll back while a bug is investigated. Every release stays scanned and reachable.