Super Speedy Search v5.53.10
= 5.53 (13th May 2026) =
* `?showweights=1` debug overlay now covers all post types and every weight, including the new taxonomy conditional match. Three fixes shipped together: (1) the new taxmatch weight from 5.53 wasn't being added to the score for single-post-type queries OR exposed as a debug column for either path — both fixed, so a single-PT search now scores taxmatch rules correctly and renders one `weight_taxmatch_<tax>_<slug>` column per rule, while multi-PT searches add a `weight_taxmatch_total` aggregate alongside the existing `weight_meta_match_total`/`weight_meta_value_total`/`weight_meta_date_total`. (2) The `RELEVANCE` total now appears in the debug output even when sorting by price/date/title etc. — previously it was only projected when `orderby=relevance` was the active sort, so admins comparing two products on a price-sorted page couldn't see what each one's relevance score *would have been*. (3) A new `wp_footer` HTML-comment fallback emits the per-post weight breakdown as `<!-- SSS post 123 "Title" [product]: RELEVANCE=… | weight_title=… | … -->` for every result row regardless of theme. Themes that override both the WC product loop template AND `the_content` (custom block themes, headless renderers) used to drop the debug entirely; the comments are always there for view-source, the visible inline rendering still happens where supported.
* Top Searches table on Analytics & Caching is now sortable and searchable. Click any of Search Term, Searches, Avg Speed or Last Searched to flip the order (default remains Searches DESC). The new filter input above the table queries against a FULLTEXT index on `search_term` — typing 3+ characters uses MATCH ... AGAINST in BOOLEAN MODE with the same `+word*` prefix-wildcard pattern as the front-end search, so 'iph' finds 'iphone 13 case' instantly even on logs with millions of rows. Tokens of 1-2 characters automatically fall back to LIKE (prefix `LIKE 'xy%'` when the whole input is short, `LIKE '%xy%'` when combined with longer tokens that already narrow the set). The FT index is added automatically on existing installs the first time the Analytics tab loads after upgrade (one ALTER TABLE on a single-column varchar; runs in seconds even on busy logs). The active time-range filter (24h / 7d / 30d) still applies to the search results so what you type matches what's visible.
* Administrator is now a user-controllable row in Elevated Search Roles. Previously the administrator checkbox was hardcoded on (disabled, always checked) so admins always saw out-of-stock, hidden and private products in search results — fine for most sites, but a few admins wanted to browse the storefront and search results the way a regular shopper would (e.g. to verify what customers actually see). The row now defaults to checked so existing installs are unchanged, but it can be unticked to make admin searches use the same visibility rules as everyone else. Other roles still default to off and remain opt-in.
* Search-result cache key now includes `orderby`, `order`, a hash of the URL path (minus `/page/N/`), and hashes of the query's explicit `tax_query` and `meta_query`. Pre-5.53.7 the key was only `(searchstring, post_type, paged, lang)`, so a search warmed at /shop/?s=foo without orderby would silently return its relevance-ordered IDs (with `orderby` overridden to `post__in`) for every subsequent /shop/?s=foo&orderby=price, every /product-category/X/?s=foo (different archive), and every price-filter or stock-filter refinement. The path component is necessary because at `pre_get_posts` time WP hasn't yet built the `tax_query` array for URL-derived archives like /product-category/gaming/ (that happens later in WP_Query:
arse_tax_query), so a tax-array-only hash wouldn't have distinguished /shop/ from /product-category/X/. Each variant now gets its own cache entry. Cache hit rate drops slightly in exchange for correctness; on busy sites the warm tier rebuilds quickly under load.
* Defensive sss_outer_orderby fallback in alter_clauses. When the user asks for `orderby=price` (meta_value_num) but the WP_Query meta_query JOIN didn't get built for whatever reason (an aggressive plugin stripped the orderby clause, another filter ran later, etc.), SSS now constructs the postmeta JOIN and ORDER BY explicitly so the outer query is never `ORDER BY LIMIT n` (which MySQL silently treats as no-ordering, losing the user's choice). Covers `meta_value_num`, `meta_value`, `date`/`publish_date`, and `title`; everything else falls back to a deterministic post_date DESC so the SQL is always valid.
* Taxonomy combination suggestions: the post type label is now a *claimable* position when the admin enabled "Show at Start" or "Show at End" on the combination row. Previously typing only the post type name (e.g. "forestry") matched the fulltext index but the post-fulltext claim algorithm dropped every row because no actual taxonomy term name was matched - so suggestions for that post type silently never appeared. Now, when the admin opted to surface the post type label in the rendered suggestion, that label counts as an extra claimable position; typing "forestry" returns rows in the Forestry post type, and typing "forestry trees" ranks the Forestry/Trees row above the Agriculture/Trees row because Forestry/Trees scored 2 of 2 versus Agriculture/Trees scoring 1 of 2. Rows where the admin chose "Don't Show" are unchanged (label not claimable, row not findable by typing the post type name) - keeps "what the user sees == what they can claim". No rebuild required; the change is in the claim algorithm at query time and the existing taxonomy-suggestions table already includes the post_type_label in its FULLTEXT-indexed combined column.
* The deferred-indexing hook surface is now aligned with Super Speedy Filters' SSF_Table_Maintenance pattern - same function naming (`sss_defer_post_update`, `sss_defer_term_update`, `sss_process_deferred_updates`), same shutdown priority (999), same DOING_AUTOSAVE and auto-draft skips, and the same wide hook coverage. SSS now hooks `wp_after_insert_post`, `save_post`, `wp_insert_post` (priority 99), `transition_post_status`, `set_object_terms`, the full WC product/variation/stock/duplicate set, bulk-edit and quick-edit AJAX, the WP importer hooks, and the explicit REST API insert/save/delete hooks for posts and terms - on top of the postmeta hooks (added_post_meta/updated_postmeta/deleted_post_meta) that SSF doesn't need but SSS does. All of them feed two deduped queues (posts + terms) drained once at shutdown, so a single product save that triggers 15 different action firings still runs one sss_update_posts batch. Same pattern as SSF, same function names where possible; a developer who learned one plugin's maintenance code immediately recognises the other's.
* Incremental indexing now picks up postmeta changes that happen after `wp_insert_post`. SSS used to hook only `wp_after_insert_post` (and a couple of WC variation hooks), which meant any importer or plugin using the pattern "create the post, then call `update_post_meta` for each field" produced an index row with empty `metavalues` - searches by SKU or other indexed meta_keys would miss those products until the next rebuild. SSS now also hooks `added_post_meta`/`updated_postmeta`/`deleted_post_meta`, gated to only the meta_keys SSS actually indexes (the Meta Keys tab plus every key referenced by metamatch/metavalue/metadate weight rules). All of SSS's per-post indexing hooks now feed a deduped queue that flushes once at PHP shutdown, so a request that fires `wp_after_insert_post` plus eight `update_post_meta` calls plus two `edited_term` calls runs a single `sss_update_posts` batch instead of eleven. Same hook surface fires from admin, REST API, Gutenberg, WP-CLI and cron - any code path that goes through WordPress core's `wp_insert_post`/`update_post_meta` benefits.
* New optional "Strict SKU search" mode on the Main tab. By default, SSS normalises punctuation in the fulltext index (so a search for `ABC.D.E` will match `ABC_D_EF` too — fast but loose, which is fine for most sites). Tick the new checkbox to layer an additional LIKE filter on the original, un-normalised meta values after the fulltext narrowing — searching for `ABC.D.E` will then return only products whose actual SKU contains the literal `ABC.D.E`, dropping the underscore-variant false positives. A new `metavalues_raw` column on wp_superspeedysearch holds the un-normalised meta string; populated from the next rebuild, then read with LIKE at query time on rows already narrowed by MATCH/AGAINST so the cost stays bounded. The filter only fires when the user's search term contains punctuation, so non-SKU searches are unaffected.
* Readiness Status now shows a warning when MySQL's `max_allowed_packet` is below 64MB. The default on many MariaDB installs is 16MB, which is fine for everyday queries but too small for the rebuild's bulk INSERT/UPDATE statements once a catalogue grows past a few thousand rows - the symptom on those sites is an intermittent "Error establishing a database connection" mid-rebuild that recovers a few seconds later. The new row prints the current value plus a link to the KB article explaining how to raise it; rebuilds keep working at any value, the warning just flags the rebuild risk.
* New "Taxonomy Conditional Match Weight" row on each per-type Weights block. Admin picks a taxonomy attached to the post type plus a term slug, and matches (or non-matches) of that term increase or decrease the relevancy score by a factor - same UX shape as the existing "Meta Conditional Match Weight". One new `term_taxonomy_ids` column on wp_superspeedysearch holds a comma-separated list of every term_taxonomy_id the post belongs to, populated via GROUP_CONCAT during rebuild; scoring uses FIND_IN_SET against that single column at query time, so there are no per-rule columns and no JOINs at search time. The one-time rebuild after upgrade adds the column - after that, adding, editing or deleting taxmatch rules takes effect on the next search with no rebuild required. The rebuild also bumps `group_concat_max_len` to 65535 so posts with many terms don't get truncated.
