# Query Loop qui affiche les mauvais articles après un changement de contexte

> Sur un template d'archive personnalisée, la boucle héritait silencieusement du mauvais contexte. Diagnostic de l'attribut inherit et correctif appliqué.

- Auteur : Clément Hadrot
- Publié le : 2022-10-06
- Mis à jour le : 2022-10-06
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/query-loop-mauvais-articles-changement-contexte/

## L’essentiel

- L'attribut inherit change tout le comportement de la boucle
- Un attribut oublié suffit à afficher un mauvais contenu
- Vérifier le contexte avant de suspecter un bug du cœur

**Symptôme.** Sur un site associatif, un template personnalisé nommé `archive-evenement.html` devait afficher uniquement les événements à venir, filtrés par une taxonomie « type d'événement ». Après publication, la page affichait pourtant l'ensemble des derniers articles du blog associatif, événements compris, sans respecter ni le type de contenu ni le filtre de taxonomie configuré manuellement dans l'inspecteur du bloc Query Loop.

Premier réflexe, largement partagé par les développeurs qui découvrent ce cas : suspecter un bug du bloc Query Loop lui-même, ou une incompatibilité avec une extension tierce installée sur le site. L'investigation a montré une cause bien plus simple, et bien plus fréquente qu'on ne le pense.

## Diagnostic : l'attribut inherit prenait le pas sur la configuration manuelle

Le bloc Query Loop possède un attribut nommé `inherit`, réglé par défaut sur `true` lors de son insertion initiale dans un gabarit d'archive. Quand cet attribut vaut `true`, le bloc ignore délibérément tous les réglages manuels de sa requête (type de contenu, taxonomie, nombre d'articles) et se contente d'hériter du contexte global de la page, c'est-à-dire de la requête principale déterminée par WordPress selon l'URL visitée.

En inspectant le HTML du template via l'éditeur de code, la ligne `<!-- wp:query {"queryId":3,"query":{"inherit":true, ...` confirmait le diagnostic : malgré tous les réglages apparemment appliqués dans l'inspecteur visuel, ce drapeau `inherit` ramenait systématiquement la boucle à la requête principale générique du site, plutôt qu'à la requête personnalisée pourtant visible dans l'interface.

## Correctif : désactiver explicitement l'héritage

```
<!-- wp:query {"queryId":3,"query":{
    "inherit":false,
    "postType":"evenement",
    "taxQuery":{"type_evenement":["a-venir"]},
    "perPage":10
}} -->
```

> L'essentiel à retenir : L'attribut inherit change tout le comportement de la boucle ; Un attribut oublié suffit à afficher un mauvais contenu ; Vérifier le contexte avant de suspecter un bug du cœur

Dans l'inspecteur du bloc, ce réglage correspond à l'interrupteur intitulé « Hériter de la requête depuis le contexte du template », qu'il suffit de désactiver pour que les réglages manuels de type de contenu et de taxonomie reprennent enfin la main sur l'affichage. Une fois ce changement appliqué et le cache de page vidé, seuls les événements à venir se sont correctement affichés.

## Pourquoi ce piège est si facile à manquer

- L'interface visuelle affiche les filtres configurés comme actifs, sans avertissement clair indiquant qu'ils sont en réalité ignorés tant que l'héritage reste activé.
- Ce comportement d'héritage est justement pensé pour les templates d'archive standards, où l'on veut précisément respecter la requête principale de WordPress ; il devient un piège uniquement sur un template personnalisé destiné à un usage différent.
- Aucune erreur ni avertissement n'apparaît dans la console ou les journaux du serveur, puisque techniquement, rien ne casse : le bloc fait exactement ce pour quoi l'héritage a été conçu.

## Prévention pour les prochains gabarits personnalisés

Depuis cet incident, la vérification du drapeau `inherit` fait partie de notre checklist systématique dès qu'un bloc Query Loop est inséré dans un template autre que les archives génériques standards du thème. Un simple passage par l'éditeur de code du gabarit, à la recherche de la chaîne `inherit`, suffit à lever le doute en quelques secondes.

> Un bloc qui fonctionne « à moitié » n'est presque jamais buggé : il applique fidèlement une règle qu'on n'a pas remarquée. Chercher cette règle avant de suspecter le logiciel fait gagner un temps précieux.

## En résumé

Ce cas illustre bien la nécessité de comprendre les attributs sous-jacents d'un bloc, au-delà de ce que l'interface visuelle laisse deviner. Une vérification du code source d'un gabarit, réflexe encore trop rare chez certains intégrateurs pressés, aurait permis de gagner l'heure entière passée à chercher ailleurs une cause bien plus banale que redoutée.

J'ai depuis pris l'habitude, sur chaque nouveau template personnalisé intégrant un bloc Query Loop, de renommer explicitement le libellé de l'interrupteur d'héritage dans mes notes de recette technique, afin que toute personne relisant le gabarit après moi ne tombe pas dans le même piège que celui rencontré sur ce site associatif.