Télécharger Super Speedy | Super Speedy Search v5.54

Quoi de neuf (Journal des modifications - Changelog) dans Super Speedy | Super Speedy Search version 5.54

• = 5,54 (11 juin 2026) =
• Erreur corrigée avec l’erreur mysqli (‘mysqli_get_server_info() : L’argument #1 ($mysql) doit être de type mysqli, null donné’) qui pourrait apparaître dans le journal d’erreurs PHP lors du hook ‘shutdown’ WordPress, généralement attribué à WooCommerce Action Scheduler. Le gestionnaire de suggestions/autocomplétion ‘sss_get_json_Suggestions()’ appelait ‘$wpdb->close()’, ce qui fermait la connexion globale partagée à la base de données en cours de requête. WordPress ne se reconnecte pas dans la même requête, donc le code suivant à utiliser la base de données lors de l’arrêt — généralement le BatchProcessingController de WooCommerce appelant Action Scheduler — a planté sur le handle de connexion désormais nul. L’appel redondant « $wpdb->close() » a été supprimé ; PHP ferme la connexion automatiquement à la fin de la requête de toute façon.
• = 5,53 (13 mai 2026) =
• L’overlay de débogage ‘ ?showweights=1’ couvre désormais tous les types de publications et tous les poids, y compris la nouvelle correspondance conditionnelle de la taxonomie. Trois corrections sont livrées ensemble : (1) le nouveau poids de taxmatch de 5,53 n’était pas ajouté au score pour les requêtes à type de publication unique OU exposé comme colonne de débogage pour l’un ou l’autre chemin — les deux corrigés, donc une recherche à un seul point évalue désormais correctement les règles de correspondance et rend un ‘weight_taxmatch__» par règle », tandis que les recherches multi-PT ajoutent un agrégat « weight_taxmatch_total » à côté de l’« weight_meta_match_total » / « weight_meta_value_total » / « weight_meta_date_total ». (2) Le total « RELEVANCE » apparaît désormais dans la sortie de débogage même lors du tri par prix/date/titre, etc. — auparavant, il n’était projeté que lorsque ‘orderby=relevance’ était le tri actif, donc les administrateurs comparant deux produits sur une page triée par prix ne pouvaient pas voir quel serait le score de pertinence de chacun. (3) Un nouveau plan de secours HTML pour le commentaire « wp_footer » émet la répartition par post du poids comme ‘« pour chaque série de résultats, quel que soit le thème. Des thèmes qui supplantent à la fois le modèle de boucle produit WC ET le « the_content » (thèmes de blocs personnalisés, moteurs de rendu headless) utilisés pour supprimer complètement le débogage ; Les commentaires sont toujours là pour voir la source, le rendu en ligne visible se fait toujours là où c’est supporté.
• Le tableau des principales recherches sur Analytics & Caching est désormais triable et consultable. Cliquez sur n’importe lequel des termes de recherche, Recherches, Vitesse moyenne ou Dernière recherche pour inverser l’ordre (par défaut reste Recherches DESC). La nouvelle entrée filtrante au-dessus de la table interroge sur un index FULLTEXT sur ‘search_term’ — en tapant 3+ caractères, on utilise MATCH … AGAINST en mode BOOLÉEN avec le même motif préfixe-joker « +mot » que la recherche front-end, donc « IPH » trouve instantanément « boîtier iPhone 13 » même sur des journaux avec des millions de lignes. Les jetons de 1 à 2 caractères reviennent automatiquement à LIKE (préfixe « LIKE ‘xy % » lorsque toute l’entrée est courte, « LIKE ‘ %xy %’ » lorsqu’ils sont combinés à des jetons plus longs qui restreignent déjà l’ensemble). L’indice FT est ajouté automatiquement sur les installations existantes la première fois que l’onglet Analytics se charge après la mise à jour (un ALTER TABLE sur un varchar à colonne unique ; s’exécute en quelques secondes même sur des journaux chargés). Le filtre à plage de temps actif (24h / 7d / 30d) s’applique toujours aux résultats de recherche, donc ce que vous tapez correspond à ce qui est visible.
• Administrateur est désormais une ligne contrôlable par l’utilisateur dans les rôles de recherche élevés. Auparavant, la case administrateur était codée en dur (désactivée, toujours cochée), donc les administrateurs voyaient toujours des produits en rupture de stock, cachés ou privés dans les résultats de recherche — ce qui convenait à la plupart des sites, mais certains administrateurs voulaient parcourir la vitrine et les résultats de recherche comme un client ordinaire (par exemple pour vérifier ce que les clients voient réellement). La ligne est désormais cochée par défaut pour que les installations existantes ne changent pas, mais elle peut être décochée pour que les recherches d’administrateur utilisent les mêmes règles de visibilité que les autres. D’autres rôles restent par défaut désactivés et restent en option.
• La clé de cache des résultats de recherche inclut désormais « orderby », « order », un hachage du chemin de l’URL (moins « /page/N/ »), ainsi que les hachages des « tax_query » et « meta_query » explicites de la requête. Avant la 5.53.7, la clé était uniquement ‘(chaîne de recherche, post_type, paged, lang)’, donc une recherche réchauffée à /shop/ ?s=foo sans orderby retournait silencieusement ses identifiants ordonnés par pertinence (avec ‘orderby’ remplacé par ‘post__in’) pour chaque /shop/ ?s=foo&orderby=price, chaque /category/X/ ?s=foo (archive différente), et pour chaque raffinement de filtre de prix ou de filtre stock. Le composant path est nécessaire car à l’époque « pre_get_posts » WP n’a pas encore construit le tableau « tax_query » pour les archives dérivées d’URL comme /product-category/gaming/ (cela se produit plus tard dans WP_Query ::p arse_tax_query), donc un hachage uniquement sur tableaux d’impôts n’aurait pas distingué /shop/ de /product-category/X/. Chaque variante bénéficie désormais de sa propre entrée de cache. Le taux de réussite du cache baisse légèrement en échange de la correction ; Sur les sites très fréquentés, le niveau chaud se reconstruit rapidement sous charge.
• Défensive sss_outer_orderby repli dans alter_clauses. Lorsque l’utilisateur demande ‘orderby=price’ (meta_value_num) mais que le WP_Query meta_query JOIN n’a pas été construit pour une raison quelconque (un plugin agressif a supprimé la clause orderby, un autre filtre a été exécuté plus tard, etc.), SSS construit désormais explicitement le postmeta JOIN et ORDER BY de sorte que la requête externe n’est jamais ‘ORDER BY LIMIT n’ (ce que MySQL traite silencieusement comme un non-ordering, perdre le choix de l’utilisateur). Couvertures « meta_value_num », « meta_value », « date »/« publish_date » et « titre » ; tout le reste revient à un DESC déterministe post_date donc le SQL est toujours valide.
• Suggestions de combinaisons de taxonomie : l’étiquette du type de publication devient désormais une *position reclaimable lorsque l’administrateur a activé « Afficher au début » ou « Afficher à la fin » sur la ligne de combinaison. Auparavant, seul le nom du type de publication (par exemple « forestry ») correspondait à l’index du texte complet, mais l’algorithme de revendication post-texte intégral disparaissait à chaque ligne car aucun nom de terme taxonomique n’était correspondu, donc les suggestions pour ce type de publication n’apparaissaient silencieusement pas. Maintenant, lorsque l’administrateur a choisi de mettre en avant l’étiquette de type de publication dans la suggestion rendue affichée, cette étiquette compte comme une position supplémentaire revendiquable ; taper « forestry » renvoie des lignes dans le type de publication Foresterie, et taper « arbres forestiers » classe la rangée Foresterie/Arbres au-dessus de la rangée Agriculture/Arbres car Foresterie/Arbres a obtenu 2 sur 2 contre Agriculture/Arbres qui ont obtenu 1 sur 2. Les lignes où l’administrateur a choisi « Ne pas afficher » restent inchangées (étiquette non réclamable, ligne non trouvable en tapant le nom du type de publication) conserve « ce que l’utilisateur voit == ce qu’il peut revendiquer ». Aucune reconstruction n’est nécessaire ; le changement se trouve dans l’algorithme de revendication au moment de la requête et la table existante de suggestions de taxonomie inclut déjà la post_type_label dans sa colonne combinée indexée en texte FULLTEXT.
• La surface de l’hameçon à indexation différée est désormais alignée avec le motif SSF_Table_Maintenance de Super Speedy Filters, même nom de fonction (« sss_defer_post_update », « sss_defer_term_update », « sss_process_deferred_updates », même priorité d’arrêt (999), même DOING_AUTOSAVE et sauts automatiques, ainsi que la même large couverture de l’hameçon. SSS accroche désormais « wp_after_insert_post », « save_post », « wp_insert_post » (priorité 99), « transition_post_status », « set_object_terms », le produit WC complet, variation/stock / double set, AJAX pour édition en bloc et édition rapide (AJAX), les hooks importateurs WP, ainsi que les hooks explicites d’insertion/sauvegarde/suppression de l’API REST pour les posts et termes en plus des hooks postmeta (added_post_meta/updated_postmeta/deleted_post_meta) dont SSF n’a pas besoin mais que SSS oui. Ils alimentent tous deux files d’attente déduppées (posts + termes) vidées une fois à l’arrêt, donc une sauvegarde de produit unique qui déclenche 15 tirs d’actions différentes exécute toujours un sss_update_posts batch. Même schéma que SSF, mêmes noms de fonctions lorsque possible ; Un développeur qui a appris le code de maintenance d’un plugin reconnaît immédiatement celui de l’autre.
• L’indexation incrémentale capte désormais les changements postméta qui surviennent après le « wp_insert_post ». SSS ne crochetait autrefois que « wp_after_insert_post » (et quelques hooks de variation WC), ce qui signifiait que tout importateur ou plugin utilisant le patron « créer le post, puis appeler « update_post_meta » pour chaque champ » produisait une ligne d’index avec des recherches vides de « métavaleurs » par SKU ou autres meta_keys indexées manquait ces produits jusqu’à la prochaine reconstruction. SSS accroche désormais aussi « added_post_meta »/« updated_postmeta »/« deleted_post_meta », verrouillés uniquement sur les meta_keys que SSS indexe réellement (l’onglet Méta Clés ainsi que chaque clé référencée par les règles de métamatch/métavaleur/poids de métadate). Tous les hooks d’indexation par post de SSS alimentent désormais une file d’attente déduppée qui se vidage une fois à l’arrêt de PHP, donc une requête qui envoie ‘wp_after_insert_post’ plus huit appels ‘update_post_meta’ plus deux appels ‘edited_term’ exécute un seul lot ‘sss_update_posts’ au lieu de onze. La même surface d’accroche s’applique à l’admin, à l’API REST, à Gutenberg, à WP-CLI et à tout chemin de code passant par les avantages « wp_insert_post » / « update_post_meta » du cœur WordPress.
• Nouveau mode optionnel « Recherche stricte du SKU » sur l’onglet Principal. Par défaut, SSS normalise la ponctuation dans l’index du texte intégral (donc une recherche pour ‘ABC. D.E’ correspondra aussi à ‘ABC_D_EF’ — rapide mais lâche, ce qui convient à la plupart des sites). Cochez la nouvelle case pour superposer un filtre LIKE supplémentaire sur les valeurs méta originales non normalisées après le rétrécissement du texte intégral — cherchez ‘ABC. D.E’ ne retournera alors que les produits dont le SKU réel contient la littérale ‘ABC. D.E’, supprimant les faux positifs de la variante underline. Une nouvelle colonne « metavalues_raw » sur wp_superspeedysearch contient la chaîne méta non normalisée ; rempli à partir de la prochaine reconstruction, puis lu avec LIKE au moment de la requête sur des lignes déjà réduites par MATCH/CONTRE pour que le coût reste limité. Le filtre ne se déclenche que lorsque le terme de recherche de l’utilisateur contient de la ponctuation, de sorte que les recherches sans SKU ne sont pas affectées.
• L’état de préparation affiche désormais un avertissement lorsque le « max_allowed_packet » de MySQL est inférieur à 64 Mo. Le défaut sur de nombreuses installations MariaDB est de 16 Mo, ce qui convient pour les requêtes quotidiennes mais est trop petit pour les instructions INSERT/UPDATE en masse de la reconstruction. Une fois qu’un catalogue dépasse quelques milliers de lignes, le symptôme sur ces sites est une « Erreur établissant une connexion à la base de données » intermittente en cours de reconstruction qui se retrouve quelques secondes plus tard. La nouvelle ligne affiche la valeur actuelle ainsi qu’un lien vers l’article de la base de connaissances expliquant comment la relever ; Les reconstructions continuent de fonctionner à n’importe quelle valeur, l’avertissement signale juste le risque de reconstruction.
• Nouvelle ligne « Taxonomie Conditionnel Match Weight » sur chaque bloc de poids par type. L’administrateur choisit une taxonomie associée au type de publication plus un terme slug, et les correspondances (ou non-correspondances) de ce terme augmentent ou diminuent le score de pertinence d’un facteur identique à la forme UX existante du « Meta Conditional Match Weight ». Une nouvelle colonne « term_taxonomy_ids » sur wp_superspeedysearch contient une liste séparée par virgules de chaque term_taxonomy_id à laquelle appartient le poste, remplie via GROUP_CONCAT lors de la reconstruction ; le score utilise FIND_IN_SET par rapport à cette seule colonne au moment de la requête, donc il n’y a pas de colonnes par règle ni de JOINs au moment de la recherche. La reconstruction unique après la mise à jour ajoute la colonne suivante, l’ajoutaille, l’édition ou la suppression des règles de TaxMatch s’applique à la recherche suivante sans qu’aucune reconstruction ne soit nécessaire. La reconstruction fait aussi passer le « group_concat_max_len » à 65535 pour que les posts avec beaucoup de termes ne soient pas tronqués.
• = 5,52 (12 mai 2026) =
• « WP SSS rebuild » vidage désormais le cache d’objets WordPress à la fin de la compilation. Sans cela, les sites disposant d’un cache d’objets persistants (Redis, Memcached) pourraient continuer à servir le blob alloptions pré-reconstruction et la liste de colonnes de recherche utilisée pour construire les requêtes MATCH() aurait un retard par rapport à l’index FULLTEXT reconstruit — se manifestant par « Impossible de trouver l’index FULLTEXT correspondant à la liste de colonnes » jusqu’à ce que le cache expire de lui-même.
• Nouvelle recherche multi-postes dans l’onglet Front-end. Choisir « Rechercher plusieurs types de posts » (l’option renommée « Ne pas définir », désormais déplacée de l’onglet Principal) expose un choix de mise en page : liste classée unique (le comportement existant à requête unique) ou sections mixtes par type de publication (une nouvelle mise en page qui exécute une requête par type de publication et affiche chaque section avec son propre modèle). Chaque chemin est indépendant, les sites qui ne touchent jamais aux nouveaux contrôles ne sont pas affectés.
• Le mode liste unique ajoute deux règles supplémentaires : « Annuler les types de publication » force la recherche à exactement les types cochés (remplace le thème / les accroches de site qui pourraient autrement décider), et « Annuler le modèle » oriente la page de résultats via l’archive du type de publication choisi — {slug}.php afin qu’une recherche multi-type puisse ressembler et se ressentir (par exemple) à l’archive produit. Les deux sont par défaut « Laissez mon site décider » afin que le comportement existant soit conservé lors de la mise à jour.
• Poids par ligne dans les requêtes multi-types à liste unique. Auparavant, SSS choisissait un type de publication et utilisait ses poids pour l’ensemble des résultats (par exemple, une requête mixte post+produit classait les produits avec des poids, en ignorant les métamatchs spécifiques au produit comme le _stock_status=boost d’instock). Chaque ligne est désormais notée en utilisant les poids de son propre type de publication via des expressions CASE par ligne sur wp_superspeedysearch.post_type. Les requêtes à type unique ne sont pas affectées et émettent le même SQL qu’auparavant.
• Une nouvelle ligne « Promotion de type de publication » sur chaque bloc de poids par type ajoute un gain constant au score de pertinence de ce type, permettant aux administrateurs de biaiser, par exemple, les produits au-dessus des publications dans une seule liste classée. Cela n’a aucun effet dans les recherches sur un seul type ni dans la disposition des sections mixtes (où l’ordre des sections est le classement).
• La mise en page Mixed Sections propose trois nouveaux modèles : templates/sss-multi-search.php (wrapper), templates/sss-multi-search-section.php (génériques) et templates/sss-multi-search-section-product.php (Woo-aware, utilise wc_get_template_part pour les cartes produits complètes). Les thèmes peuvent prendre le dessus à /recherche ultra-rapide/.php. Chaque en-tête de section prend en charge un titre configurable avec un ‘« Un substitut temporaire au moment du rendu.
• Politique exclude_from_search à l’échelle du plugin. Les types de publications enregistrés avec « exclude_from_search => vrai » ne sont plus proposées comme options nulle part : Podés, suggestions, types de posts Ajax, menu déroulant type de publication par défaut, liste de recherche multi-recherches, menu déroulant « Ajouter une section » en sections mixtes, widgets, bloc Gutenberg. L’intention de l’auteur du type de publication (exclure de la recherche) est désormais respectée par l’interface de SSS. Les sites qui souhaitent intentionnellement exposer un tel CPT peuvent le réactiver via le filtre sss_post_types_args existant. Effet secondaire lors de la mise à jour : un CPT exclu précédemment configuré dans (par exemple) l’onglet Ajax disparaîtra de l’interface d’administration mais ses paramètres sauvegardés restent dans sss_options.
• Les suggestions de combinaisons de taxonomie sont désormais classées selon la profondeur réelle des mots tapés par l’utilisateur sur les termes de la ligne, et non selon la profondeur brute. Chaque mot tapé revendique au maximum un terme, et les lignes où chaque terme a été revendiqué (parfait-ajustement) sont mises en avant ; Dans ce niveau, plus de conditions ont remporté des victoires (un match de 3 mandats bat un match de 2 mandats bat un 1 mandat). L’ancien réglage « multiplicateur de priorité de profondeur » a été supprimé : il pouvait pousser les triples en haut même lorsque l’utilisateur ne tapait qu’un seul mot qui touchait accidentellement deux termes dans la ligne, ce qui a donné des suggestions trompeuses. Les lignes où la recherche ne correspondait qu’à l’étiquette du type de publication (aucun terme revendiqué) ne sont plus retournées.
• Nouveau paramètre « Appariement de jetons » dans la section Suggestions de taxonomie : Optimal (par défaut) trouve la meilleure attribution token-terme, quel que soit l’ordre typé ; L’ordre strict exige que les jetons réclament les termes de gauche à droite dans l’ordre tax_a → tax_b → tax_c de l’admin, donc la saisie hors ordre donne des scores plus bas. Choisissez Strict si vous définissez les taxonomies dans l’ordre dans lequel vous attendez que les utilisateurs tapent.
• Les URL de suggestions de combinaison de taxonomie passent désormais par des filtres Super Speedy quand c’est actif, donc des destinations comme « Dogs ▸ Dog Grooming ▸ Cool Dogs Co ▸ Red » tombent sur le formulaire permalink joli (par exemple /category-product/dogs/dog-grooming/brands/cool-dogs-co/color/red/) au lieu de mélanger la base jolie avec des args de requête bruts ( ?product_brand=cool-dogs-co&pa_color=red). Sans SSF, l’URL de requête-arg existante est toujours produite. Nécessite l’extension SSF Pretty URLs pour le formulaire embelli.
• Suggestions de taxonomie Les lignes combinées disposent désormais d’un menu déroulant « Afficher le nom du type de poteau » (Ne pas afficher / Afficher au début / Afficher à la fin) afin que vous puissiez décider par rangée si vous souhaitez mettre en avant l’étiquette de type de poteau dans la suggestion (par exemple « Excavatrices chenilles ▸ Machine ») et où elle apparaît. Par défaut, c’est Ne pas montrer. Changer cette préférence entre en vigueur immédiatement, pas besoin de reconstruire.
• Les suggestions de combinaison de taxonomie mettent désormais en gras les jetons de préfixe correspondants (par exemple, taper « dog to » en gras « Dog » et « To » dans « Dog Toys »), en correspondant aux suggestions existantes du titre post-titre, et le style déroulant (remplissage, survolation, couleur du lien) correspond désormais aux listes post-titre et taxonomique pour une cohérence visuelle.
• Les suggestions de combinaisons de taxonomie passent désormais par le chemin ultra-rapide ajax mu-plugin lorsque « Activer notre ultra-rapide ajax » est activé, auparavant les combinaisons tombaient toujours dans le chemin standard de l’API WP REST, tandis que les suggestions post-titre et taxonomie utilisaient le chemin rapide, donc les combinaisons étaient nettement plus lentes que les autres types de suggestions. (Ça pousse le plugin mu inclus à la version 1.14.3, il se redéploie automatiquement lors du prochain chargement de la page d’administration.)
• Suggestions de taxonomie Les lignes combinées filtrent désormais les menus déroulants Taxonomie A/B/C pour n’afficher que les taxonomies enregistrées pour le type de publication sélectionné, afin que vous ne puissiez pas choisir accidentellement une taxonomie qui ne s’applique pas.
• Les nouvelles suggestions de taxonomie proposent des lignes de suggestions pré-calculées qui combinent 1, 2 ou 3 termes de taxonomie pour un type de poteau spécifique (par exemple « Caterpillar Excavators Machine ») avec des comptes précis de poteaux par rangée. Seules les combinaisons qui existent réellement sur les publications sont indexées. Les suggestions apparaissent dans le menu déroulant ajax ci-dessous des suggestions de jetons existantes. Configurez, dans la nouvelle section Suggestions de taxonomie de l’onglet Suggestions, choisissez un type de publication et 1 à 3 taxonomies par ligne ; La profondeur se déduit du nombre de places de taxonomie que vous occupez.
• La même paire (marque, catégorie) qui existe dans plusieurs types de poteaux produit une rangée de suggestions par type de poteau, chacune avec son propre nombre de publications et son propre label de type de poste, donc les utilisateurs considèrent par exemple « Caterpillar Excavators Machine » et « Caterpillar Excavators Industry » comme des rangées distinctes lorsque les deux contiennent des produits.
• Les URL d’archive filtrées pour les clics combinés par taxonomie sont construites au moment de la lecture et se retrouvent sur une page d’archive WooCommerce/taxonomie, avec les autres termes appliqués comme args de requête, sans dépendance aux filtres Super Speedy.
• Nouveau point de terminaison REST /wp-json/sss/v1/combinations/ renvoie les combinaisons correspondantes sous forme de JSON.
• Nouvelle sous-commande WP-CLI : wp sss rebuild taxonomy_suggestions reconstruit uniquement la table des combinaisons de taxonomie. WP SSS Rebuild (sans portée) et WP SSS Rebuild incluent désormais également des suggestions de taxonomie comme dernière étape ; Recherche de reconstruction WP SSS et suggestions de reconstruction WP SSS continuent de les ignorer. Recommandé : ajouter la reconstruction WP SSS à votre crononglet serveur pour des rafraintes nocturnes si la reconstruction déclenchée par l’admin atteint un délai d’expiration PHP de votre hébergement.
• L’onglet Avancé liste désormais toutes les commandes de reconstruction WP-CLI avec l’indication de préférer la CLI lorsque les reconstructions déclenchées par l’admin échouent en raison des limites d’hébergement (délai PHP de 30 secondes, limites mémoire, WP-cron peu fiable).
• Rebuild saute les types de suggestions désactivés si Activer les suggestions de titre de publication est désactivé, le pipeline de génération de tokens post-titre n’est pas exécuté (auparavant, il reconstruisait la table de suggestions que quelque chose puisse ou non). Il en va de même pour les suggestions d’activation de la taxonomie. La table de suggestions existante est restée en place, donc réactiver la fonctionnalité plus tard ne nécessite pas de reconstruire pour recommencer à fonctionner.
• L’onglet Suggestions restructuré en deux sections : Suggestions de titres de publication (les suggestions existantes basées sur des jetons, désormais avec un sélecteur de types de publications pour pouvoir scanner des types de posts spécifiques à la recherche de jetons de suggestion au lieu de dépendre de la sélection Ajax Post Types) et la nouvelle section Suggestions de Taxonomie.
• L’onglet Ajax « Activation des suggestions Ajax » a été renommé « Activer les suggestions » avec deux cases à cocher : Activer les suggestions de titres de publication, Activer les suggestions de taxonomie.
• Le champ « Suggérer des taxonomies » hérités sur l’onglet Ajax est désormais caché pour les nouveaux utilisateurs via une migration one-shot ; Les sites existants qui avaient déjà coché les taxonomies le gardent visible afin que leur configuration continue de fonctionner sans changement.
• Correction d’un écart entre la barre d’outils wp-admin et la barre latérale gauche qui apparaissait sur chaque page d’administration sous PHP 8.2+ la classe SSS créait un dynamique sans les déclarer, déclenchant E_DEPRECATED avertissements qui ont poussé WP à ajouter une classe d’erreur de .php au corps.
• Correction d’un avertissement de $wpdb indéfini dans la liste de compilation de l’état de préparation.
• = 5,51 (18 avril 2026) =
• Renommé onglet « Search Analytics » en « Analytics & Caching » pour mieux refléter les options de cache qu’il contient
• Ajout d’un cache automatique pour les recherches lentes : met en cache tout terme de recherche dont la vitesse moyenne suivie dépasse un seuil configurable (par défaut > 250 ms) pendant une durée configurable (par défaut 20 minutes). Fonctionne en parallèle avec les options existantes basées sur la fréquence et l’auto-cache top-X
• Correction de la vitesse moyenne manquante dans la table Analytics & Caching, les recherches de requête principale étaient surveillées avant l’exécution de la requête, donc aucune vitesse n’était enregistrée (la colonne montrait toujours -). Maintenant, il stocke l’heure de début dans pre_get_posts et enregistre les ms écoulés depuis the_posts filtre après l’exécution effective de la requête. Le cache automatique de recherche lente dispose désormais de données réelles avec lesquelles travailler.
• L’onglet Méta-Recherche se charge désormais instantanément dès la première vue de la page, seule une liste blanche soigneusement sélectionnée de méta-clés couramment recherchées (SKU, MPN, GTIN, ISBN, EAN, UPC, ASIN, marque, fabricant, modèle, fournisseur, code fournisseur, numéro de pièce, sous-titre, signature, présentateur, résumé, note d’achat, description de la variante, etc.) est interrogée contre wp_postmeta via une recherche IN indexée
• Ajout du bouton « Récupérer toutes les clés méta » dans l’onglet Recherche Méta (remplaçant « Actualiser la liste des clés méta ») qui exécute le scan exhaustif postméta à la demande via AJAX
• Les meta-clés déjà sélectionnées apparaissent toujours dès le chargement de la première page, donc les paramètres sauvegardés restent visibles même si ce n’est pas dans la liste blanche
• Ajout d’un nouveau filtre sss_meta_keys_whitelist pour que la liste blanche puisse être étendue par site
• Ajout d’une exclusion pour toute meta_key contenant « post_id » (par exemple foo_post_id_123) du scan exhaustif capture les plugins qui intègrent les identifiants de publication dans des noms de clés meta