Les recherches et filtres de produits WooCommerce sont incohérents

Repérer l’écart entre une fiche et sa liste

Une fiche affiche le nouveau prix, mais le tri la place parmi les produits plus chers. Une autre est visible par son adresse directe, mais disparaît lorsque le visiteur choisit une couleur. Ces deux résultats peuvent venir de données dérivées utilisées par le catalogue. Ils peuvent aussi être expliqués par la configuration de la fiche, le filtre utilisé ou une réponse en cache. Notez précisément la page, le tri, la recherche ou les filtres actifs et le résultat attendu. Conservez aussi l’heure de l’import ou de la modification qui a précédé le problème.

Commencez avec une fiche simple touchée, une fiche comparable qui fonctionne et une variation si le problème concerne des produits variables. Sur chaque exemple, relevez l’identifiant, la référence, le prix, l’état de stock et les attributs utiles au test. Ouvrez la même page avec les mêmes critères dans une fenêtre sans connexion. Une différence entre cette vue et celle de l’administrateur peut signaler une variation de cache, de visibilité ou de prix liée au compte. Votre premier objectif est de rendre l’écart reproductible sur une requête précise.

Reproduire la requête qui donne le mauvais résultat

Sur la liste de départ, enlevez les filtres et vérifiez que le produit appartient au périmètre. Un article qui se trouve dans une autre catégorie peut rester absent même avec un index correct. Ajoutez ensuite un seul critère. Testez le tri par prix, puis la référence dans l’écran ou la recherche qui accepte réellement les références, puis un filtre par attribut. Notez quelles opérations reproduisent l’écart. Si l’adresse change avec les réglages du filtre, conservez chaque adresse avec le résultat attendu.

Comparez si possible l’élément qui pose problème à une liste native de la boutique sur une copie. Un outil de recherche externe ou un bloc personnalisé peut utiliser ses propres données, et toutes les recherches publiques ne prennent pas les références comme critère. Si le comportement diffère uniquement dans ce composant, identifiez le mécanisme de recherche qui lui appartient avant de reconstruire les index WooCommerce. Si l’écart apparaît également dans la requête native, vérifiez les produits et leurs variations. Un problème qui se répète avec le même attribut sur plusieurs produits justifie de contrôler le chemin de filtrage.

Choisir un terme et identifier les trois témoins

Partez d’un filtre par attribut qui donne une réponse précise. Prenez par exemple la boutique avec la couleur Bleu, sans filtre de prix ni deuxième attribut. Notez l’URL, le composant qui affiche la liste et l’endroit où le visiteur applique le filtre. Sur un catalogue, la réponse attendue est généralement une carte du produit parent correspondant au terme. La variation elle-même se choisit ensuite sur la fiche. Un filtre qui affiche le parent ne doit donc pas être évalué en cherchant une carte séparée pour chaque taille ou couleur.

Sur la copie, choisissez un produit visible qui doit ressortir et relevez l’identifiant du parent et de la variation bleue. Ajoutez deux contre-exemples utiles. Le premier a le parent visible et le Bleu épuisé, avec une autre couleur en stock pour que le produit reste visible sans le filtre. Le second a du Bleu en stock, mais son parent est masqué du catalogue. Lancez les essais en session anonyme, dans la même liste, avec le même terme et les mêmes réglages. Le parent masqué doit rester absent de la boutique même si son URL directe fonctionne.

Commencez par relever la liste sans filtre et ensuite avec le terme seul. Si le parent manque dès le premier relevé, vérifiez son statut, sa visibilité, la catégorie ou les conditions de la collection avant de chercher une ligne d’attribut. S’il n’apparaît qu’en retirant le terme, examinez quelle variation satisfait réellement ce terme. Un parent peut être en stock grâce au Gris, tandis que le Bleu est épuisé. Le résultat dépend alors du réglage qui masque les articles épuisés et du mécanisme de filtrage.

Approche 1 — Corriger l’attribut, le stock ou la visibilité à la source

Avec les droits de modifier les produits, ouvrez **Produits → Attributs** et retrouvez l’attribut global utilisé par le filtre. Dans les termes, relevez le libellé et le slug, par exemple « Bleu » et bleu. Puis ouvrez le produit variable dans **Produits**. Dans **Données produit → Attributs**, vérifiez que le parent utilise bien cet attribut global, qu’il contient le terme voulu et qu’il est utilisé pour les variations. Une valeur locale saisie comme texte sur la fiche peut porter le même libellé. Elle ne fournit pas au filtre global la même taxonomie ni le même terme.

Dans **Données produit → Variations**, ouvrez la déclinaison exacte. Vérifiez le terme attribué, l’activation de la variation et son prix. Dans le cas d’une combinaison Bleu / M, vérifiez le stock de cette combinaison. Le stock du Bleu / L et le stock total de la fiche ne répondent pas à la question. Si la variation gère sa quantité, relevez sa quantité, le statut de stock et l’autorisation des commandes en réapprovisionnement. Si le stock est partagé au niveau du parent, relevez aussi ses réglages d’inventaire. Quand un import maintient ces valeurs, corrigez la source qui doit les fournir au prochain passage.

Contrôlez ensuite la **Visibilité du catalogue** du produit parent. Un parent visible uniquement dans la recherche peut manquer dans la boutique. Un parent masqué peut rester accessible par son URL directe. Vérifiez la portée voulue avant de changer ce réglage. Relevez également **WooCommerce → Réglages → Produits → Inventaire**, notamment l’option qui masque les articles en rupture. Gardez sa valeur pour le test et vérifiez que le filtre de votre boutique la prend en compte. Pour expliquer un doute, comparez la variation bleue épuisée en faisant varier ce réglage sur la copie. La variation du résultat devient alors un témoin de cette règle de stock.

Corrigez seulement la donnée démontrée, puis enregistrez et rouvrez le parent et la variation pour confirmer les valeurs conservées. Refaites le test sans filtre, avec Bleu et, si la fiche utilise plusieurs attributs, avec la combinaison exacte sur la fiche produit. Le résultat attendu est le retour du parent dans les listes où il doit apparaître et une variation sélectionnable selon les règles de vente prévues. Pour revenir en arrière, rétablissez les valeurs relevées dans le même écran ou dans l’intégration qui les alimente. Une modification de visibilité ou de stock s’applique à d’autres listes et peut toucher des clients. Faites le test sur la copie avant de la reproduire ailleurs.

Identifier laquelle des deux tables est en jeu

WooCommerce maintient une table wc_product_meta_lookup, précédée du préfixe de l’installation, pour rendre certaines recherches et certains tris plus efficaces. Elle contient notamment des données liées aux références, aux prix et au stock des produits. Si la fiche est correcte mais que plusieurs produits importés sont triés d’après d’anciennes valeurs, cette table constitue une piste. Un filtre de prix et un filtre de couleur ne lisent pas nécessairement les mêmes données.

La table wc_product_attributes_lookup sert au filtrage par attributs du catalogue. Elle aide notamment à représenter les termes des attributs et leur relation avec les produits et variations. Si le filtre « Bleu » échoue alors que le tri et l’affichage des prix sont cohérents, vérifiez la configuration de l’attribut, de la variation et du filtre avant de cibler cette table. Le fait que les deux noms se terminent par lookup ne suffit pas à choisir l’outil. Il existe aussi des tables de recherche de commandes et d’autres données dérivées. Limitez votre intervention au type de résultat que vous avez effectivement reproduit.

Contrôler les données avant de reconstruire

Dans l’éditeur WooCommerce, relevez les valeurs que le produit doit réellement utiliser. Vérifiez son statut de publication et sa visibilité catalogue. Pour un prix, contrôlez la période de promotion et la différence entre le prix du produit parent et celui de la variation. Si la taxe ou la devise varie selon le contexte de visite, comparez les résultats dans le même contexte. Une variation disponible et une variation épuisée peuvent aussi influencer la plage de prix que le client voit.

Pour un filtre par attribut, confirmez que l’attribut global et son terme exact sont utilisés là où le filtre les attend. Deux libellés « Bleu » peuvent correspondre à un terme global et à un texte saisi uniquement sur la fiche. Pour un produit variable, vérifiez la correspondance entre le terme, la variation et la disponibilité, puis comparez avec le réglage qui masque les produits épuisés. Si une donnée est incorrecte à la source, corrigez-la au moyen de l’éditeur ou de l’intégration responsable. Une table régénérée à partir d’une donnée erronée peut reproduire le problème sans afficher d’erreur.

Utiliser un produit témoin pour localiser la rupture

Sur une copie de l’état qui présente l’écart, comparez les produits affectés avec un produit créé ou mis à jour par le parcours habituel de WooCommerce. Prenez des exemples comparables. Une fiche simple ne remplace pas le test d’une variation si le défaut apparaît seulement pour les variations. Notez quels produits viennent d’un même lot, à quelle heure ils ont été mis à jour et par quel outil. Demandez si le flux passe par les interfaces de WooCommerce ou écrit directement dans les données de WordPress.

Sur un produit témoin de la copie, enregistrez la correction attendue via l’éditeur, puis vérifiez la liste. Si la mise à jour ordinaire fonctionne sur ce produit alors que les autres fiches du lot restent incohérentes, le flux d’import devient une piste prioritaire. Une mise à jour des attributs peut être différée selon la configuration, ce qui impose de vérifier les tâches avant de conclure. Lorsque le produit reste incohérent après l’enregistrement et que sa donnée réelle est confirmée, choisissez l’outil de régénération en fonction de la requête qui échoue.

Régénérer la table générale des produits

Si plusieurs écarts de références, de prix ou de stock concernent la table générale, ouvrez WooCommerce puis État puis Outils. Repérez Regenerate product lookup tables ou son libellé traduit. Avant le lancement, confirmez la sauvegarde utilisable et la disponibilité d’une fenêtre de travail adaptée à la taille du catalogue. Sur une boutique active, coordonnez la régénération avec les imports ou synchronisations qui mettent les mêmes produits à jour. Préparez les témoins qui serviront au contrôle final.

Lancez l’outil une fois sur la copie. WooCommerce indique que la régénération peut se poursuivre au moyen de tâches. Le bouton passe à un état de traitement, avec un lien pour suivre l’avancement ou consulter les mises à jour en file lorsque WP-Cron est désactivé. Gardez l’heure de départ et observez si les traitements progressent. Si les tâches terminent et que les requêtes témoins restent erronées, reprenez la vérification de la donnée et du composant de recherche. Une reconstruction réussie confirme la fin du traitement prévu. Elle ne garantit pas que la requête publique utilisait cette table.

Régénérer les attributs du seul produit touché

Si les écarts concernent un filtre par attribut, repérez l’outil Regenerate the product attributes lookup table dans le même écran. Lorsque l’outil propose un sélecteur de produit, choisissez d’abord le produit témoin. WooCommerce reconstruit alors les données d’attributs pour ce produit. Après cette étape, répétez exactement le test de filtre, avec la même catégorie et le même état de visibilité. Si la fiche revient, vérifiez une variation disponible et une variation épuisée selon la règle de votre boutique.

Pour une incohérence étendue et démontrée, l’outil sans sélection reconstruit la table complète par tâches planifiées. Prévoyez l’impact sur les filtres. Pendant la reconstruction complète, WooCommerce désactive l’usage de cette table et ne permet pas de la réactiver à ce moment-là. Après le traitement, vérifiez l’état de l’option dans les réglages avancés des produits et comparez-le à l’état relevé au départ. Si l’outil signale une interruption, lisez son état et les messages avant de reprendre. Ne forcez pas l’activation d’une table potentiellement incomplète. Le choix entre une reprise et une nouvelle reconstruction dépend de ce qui a déjà été traité.

Approche 2 — Vérifier puis régénérer les données du produit visé

Lorsque la fiche et la visibilité correspondent à ce que vous attendez, identifiez le moteur qui applique le filtre. Refaites d’abord le test sur la liste native de la boutique, si elle est disponible sur la copie. Un bloc de collection, un moteur de recherche externe et une extension de filtres peuvent modifier la requête ou employer leur propre index. Si le défaut se limite à l’un d’eux, relevez son nom, la collection et la requête. Suivez sa procédure de vérification avant de régénérer la table native.

Pour le parcours natif fondé sur l’index, ouvrez **WooCommerce → Réglages → Produits → Avancé**. Dans la section de la table de recherche des attributs, relevez si l’utilisation de la table et les mises à jour directes sont activées. Un catalogue peut utiliser un autre chemin de filtrage lorsque la table est désactivée. L’état de la case indique la configuration de la boutique. Un responsable technique peut confirmer dans la requête native si la table des attributs a réellement été consultée. Une mise à jour différée peut expliquer un court écart après un import ou un enregistrement. Vérifiez les actions planifiées et leurs heures de traitement avant de conclure que l’index est incomplet.

Lorsque la requête utilise la table wc_product_attributes_lookup, comparez les données de la variation aux lignes dérivées. Pour la couleur utilisée par une variation, repérez l’identifiant de la variation, l’identifiant du parent, la taxonomie de l’attribut global et l’identifiant du terme. La colonne in_stock indique si la ligne est indexée comme disponible pour ce filtre. Vérifiez sur une copie si la ligne attendue manque, vise un autre terme ou conserve un état périmé. Relevez le préfixe réel de l’installation si vous faites cette lecture technique. La table wc_product_meta_lookup, qui sert à d’autres recherches et tris, n’est pas l’index de ces termes.

Avec les droits de gestion WooCommerce et une sauvegarde utilisable, ouvrez **WooCommerce → État → Outils** sur la copie. Repérez **Regenerate the product attributes lookup table** ou son libellé traduit. Dans le sélecteur, choisissez le produit parent identifié. Assurez-vous que le produit reste sélectionné avant de lancer. Un sélecteur laissé vide peut déclencher la régénération de la table entière. Si votre version ne propose pas ce sélecteur, vérifiez la procédure disponible pour votre version sur la copie. L’outil de régénération générale des tables produits est une autre opération.

Après l’exécution, relisez le terme et le stock de la variation, puis rejouez la requête d’origine. Le parent attendu doit revenir si sa ligne d’attribut était seule en cause. Le parent masqué doit rester absent et la variation épuisée doit suivre le réglage d’inventaire. Si l’index redevient incohérent après le prochain import, comparez une mise à jour faite par l’éditeur avec une mise à jour équivalente faite par l’import. Vérifiez ensuite si le mécanisme de mise à jour différée a été exécuté. La régénération reconstruit des données dérivées. Pour revenir à un état de test précis, repartez de l’instantané de la copie. Pour revenir sur une donnée produit, corrigez cette donnée dans l’éditeur ou le système source et vérifiez à nouveau l’index.

Avec WP-CLI et une version de WooCommerce qui fournit wc palt, vous pouvez lancer la même reconstruction ciblée depuis le dossier WordPress. Remplacez 123 par l’identifiant du produit parent et l’URL par celle du site ou du sous-site de la copie. L’option --disable-db-optimization utilise le parcours sans requêtes de régénération optimisées, comme dans la recette SQLite. Après le message de fin, reprenez la même liste avec le même filtre.

wp --url=https://boutique.exemple.test wc palt regenerate_for_product 123 --disable-db-optimization

Vérifier les trois causes avec le même filtre

La recette locale a fait interroger l’archive native de produits par WordPress 7.1.4 et WooCommerce 11.2.1. Les trois parents fictifs ont chacun reçu une variation bleue et une variation grise d’un même attribut global. L’un avait du Bleu disponible, le deuxième avait du Bleu épuisé et du Gris disponible, et le troisième avait du Bleu disponible avec un parent masqué. Sans filtre, les deux parents visibles sont ressortis. Avec le filtre Bleu, l’index des attributs activé et le masquage des ruptures, seul le premier parent est ressorti.

Un relevé séparé a neutralisé le masquage des ruptures pour une requête de la copie. Les deux parents visibles sont alors ressortis sur Bleu. Le parent masqué est resté absent. La recette a ensuite rétabli les conditions de départ et retiré uniquement la ligne d’attribut de la variation bleue disponible dans la base jetable. Sa quantité est restée à quatre. Le parent figurait toujours dans le catalogue sans filtre et avait disparu avec Bleu. La requête a bien consulté la table d’attributs.

Le traitement natif de l’outil de régénération ciblé sur le parent a rétabli sa ligne. Le même filtre a de nouveau retrouvé ce parent, tandis que les deux contre-exemples sont restés exclus. La commande WP-CLI ciblée a donné le même résultat après un second retrait de la ligne. Ces mesures portent sur l’archive native et sur un terme global unique. Si votre filtre vient d’une autre collection ou d’une extension, gardez les mêmes témoins et reprenez le test dans ce composant. Pour une combinaison comme Bleu et M, contrôlez ensuite la fiche produit. La présence du parent dans les résultats ne démontre pas à elle seule qu’une variation correspondant à toute la combinaison peut être achetée.

Suivre les tâches avec le contexte de l’incident

Ouvrez les actions planifiées depuis l’écran d’état de WooCommerce ou le lien de progression fourni par l’outil. Relevez le nom des actions associées à cette reconstruction, leur heure et leur état. Des tâches en attente qui diminuent progressivement peuvent être normales. Une tâche échouée mérite la lecture de son message. Vérifiez aussi si d’autres traitements de catalogue occupent la même fenêtre. Pour un site dont les tâches WordPress passent par un déclencheur serveur, faites confirmer son fonctionnement par le mainteneur.

Sur une copie, vous pouvez reproduire le lancement et relever combien de temps l’avancement reste observable. Sur le site actif, adaptez la fenêtre à la taille du lot et au fonctionnement habituel des tâches. Évitez de relancer l’outil à chaque rechargement si des opérations sont déjà en cours. Ne déclenchez pas en masse d’autres tâches au nom proche. Une file peut contenir des notifications, des synchronisations ou des paiements qui ne font pas partie de cet incident. Lorsque la progression s’arrête, conservez les preuves et traitez le blocage de la tâche ciblée avant de juger le rendu du catalogue.

Valider sur les mêmes produits et les mêmes requêtes

Attendez la fin du traitement avant de comparer les résultats à ceux relevés au départ. Pour le prix, refaites le tri dans les deux sens sur quelques produits aux prix nettement distincts. Pour une référence, reprenez la recherche exacte dans l’écran concerné et vérifiez que le résultat ouvre la bonne fiche. Pour un filtre par attribut, appliquez le terme seul, puis ajoutez le deuxième filtre utilisé par les visiteurs. Vérifiez un produit qui doit apparaître et un autre qui doit rester absent. Répétez ces contrôles avec une variation, si le défaut portait sur le stock ou sur les attributs des variations.

Comparez le résultat dans une fenêtre publique et sur la copie de référence. Si seul le public reçoit l’ancien résultat et que le site propose une invalidation ciblée, testez les adresses concernées après invalidation. Si une application de recherche externe reproduit encore l’écart, comparez sa date de dernière synchronisation à la date de correction. Un tri rétabli dans le catalogue natif et encore erroné dans cette application indique quel composant examiner ensuite.

Préparer un retour adapté à la correction

Conservez l’état initial des réglages de filtrage et la sauvegarde prise avant la régénération. L’outil reconstruit des données dérivées. Il ne sert pas à annuler un import erroné, ni à retrouver un prix d’origine. Si l’enquête a révélé des valeurs sources incorrectes, restaurez ces valeurs par le parcours WooCommerce ou par un import correctif testé. Comparez ensuite les quelques fiches choisies et vérifiez que les données dérivées suivent. Si vous avez seulement changé un réglage de filtrage et que la table est saine, rétablissez la valeur consignée puis refaites les requêtes témoins.

Si un traitement complet a été interrompu, laissez l’usage de la table d’attributs dans l’état prévu par WooCommerce jusqu’à ce qu’une reprise ou une nouvelle régénération aboutisse. Une restauration complète d’une boutique active implique des données qui ont pu changer entre temps. Faites évaluer ces écritures avant toute restauration intégrale. Les heures des nouvelles commandes et les synchronisations en cours déterminent ce qui doit être rapproché. Préférez une correction dont le périmètre correspond à l’écart observé et dont le résultat se vérifie avec vos produits témoins.

Éviter la récidive au prochain import

Remettez au responsable de l’import le relevé des produits touchés, la date, le type de champ et le résultat de l’enregistrement par l’éditeur. Demandez-lui de vérifier comment l’intégration crée et met à jour les produits et variations. Faites passer un petit lot de référence dans la copie par le même mécanisme que la production. Comparez les valeurs dans les fiches et dans les listes après la fin des actions planifiées. Incluez un produit variable, un changement de prix et un attribut global si ces trois cas sont présents dans l’import.

L’outil de régénération fait partie de l’extension gratuite WooCommerce. Une extension de recherche supplémentaire peut être utile si le besoin est différent, par exemple une recherche métier dans un catalogue externe. Pour une incohérence apparue juste après un import, stabilisez d’abord la mise à jour du catalogue existant. Consignez les écrans qui lisent les références et ceux qui utilisent les attributs. Au prochain contrôle, cette carte évite de traiter deux résultats d’apparence similaire comme s’ils dépendaient forcément de la même table.

Décider quand reprendre les mises à jour

Fixez un critère de reprise avant de réactiver un flux de catalogue suspendu. Si la régénération est terminée mais que le premier lot d’essai recrée l’écart, gardez ce lot comme preuve et revenez au mécanisme d’import. Si les témoins restent cohérents après le lot, surveillez le premier passage normal avec les mêmes vérifications. Identifiez une personne responsable de chaque résultat lorsque plusieurs outils interviennent entre la fiche et la liste.

1. Comparez les produits affectés et témoins dans l’éditeur, la fiche publique et la requête qui reproduisait le défaut.
2. Confirmez la fin des actions concernées et l’état du réglage d’usage de la table des attributs.
3. Faites passer un petit lot contrôlé par le flux d’import et attendez le traitement prévu par WooCommerce.
4. Refaites la recherche, le tri ou le filtre avec les mêmes paramètres et conservez l’heure du contrôle.
5. Si l’écart revient, notez la première fiche touchée et suspendez le flux qui la met à jour avant d’engager une nouvelle reconstruction générale.