# Un bloc Query qui ignore le tri choisi dans l’inspecteur : la cause la plus fréquente

> Le réglage de tri du bloc Query semble accepté dans l'éditeur, mais l'ordre affiché en façade ne correspond jamais à ce choix. Voici pourquoi.

- Auteur : WordPress Développement
- Publié le : 2025-02-04
- Mis à jour le : 2025-02-04
- Catégorie : Éditeur de site (FSE)
- URL : https://www.wpmoderne.fr/fse/query-loop-tri-inspecteur-ignore/

## L’essentiel

- Le tri de l'inspecteur écrit des attributs de bloc, pas une requête directe
- Un filtre ou un bloc parent peut réécrire ces attributs en aval
- Inspecter la requête générée règle le doute en une commande

`orderby: "title", order: "asc"` : c'est exactement ce qu'affichent les attributs du bloc dans l'éditeur de code. Et pourtant, en façade, les articles restent triés par date décroissante, comme si le réglage n'avait jamais existé. Ce cas revient régulièrement sur les sites qui combinent le bloc Query avec une extension tierce ou un filtre de requête maison.

La cause ne se trouve presque jamais dans l'inspecteur lui-même, qui écrit correctement ses attributs. Elle se trouve dans la chaîne qui va de ces attributs jusqu'à la requête SQL réellement exécutée — une chaîne plus longue qu'il n'y paraît.

## Ce que fait vraiment l'inspecteur du bloc Query

Le réglage de tri dans l'inspecteur modifie l'attribut `query` du bloc, un objet qui contient notamment les clés `orderby` et `order`. Cet attribut est ensuite converti en arguments de `WP_Query` au moment du rendu, via la fonction interne du bloc `build_query_vars_from_query_block()`, avant l'exécution de la requête elle-même.

Rien dans ce chemin ne garantit que les valeurs restent inchangées jusqu'au bout : plusieurs points d'extension du cœur peuvent légitimement les modifier après coup.

## Où l'ordre se perd réellement

Trois causes couvrent la grande majorité des cas observés :

- Un filtre `pre_get_posts`, souvent posé par une extension de filtrage ou de recherche, qui réécrit `orderby` sans condition sur le contexte d'appel — il s'applique alors aussi aux requêtes du bloc Query, pas seulement à la requête principale visée à l'origine.
- Un bloc Query imbriqué dans un autre bloc Query : l'attribut `inherit` activé sur l'un des deux fait que la requête suit le contexte de la page plutôt que ses propres réglages de tri.
- Une source de liaison personnalisée (Block Bindings) ou un attribut `query` partiellement écrasé par un pattern synchronisé qui a été mis à jour après la création initiale du bloc, laissant une valeur de tri obsolète dans certaines instances.

> L'essentiel à retenir : Le tri de l'inspecteur écrit des attributs de bloc, pas une requête directe ; Un filtre ou un bloc parent peut réécrire ces attributs en aval ; Inspecter la requête générée règle le doute en une commande

## Isoler la cause en pratique

La méthode la plus rapide consiste à afficher la requête réellement générée plutôt que de deviner à partir du comportement observé. Un filtre temporaire sur `pre_get_posts`, placé en tout dernier (priorité élevée), permet de journaliser les arguments juste avant l'exécution :

```
add_action( 'pre_get_posts', function( $query ) {
    if ( ! is_admin() && $query->get( 'orderby' ) ) {
        error_log( print_r( array(
            'orderby' => $query->get( 'orderby' ),
            'order'   => $query->get( 'order' ),
        ), true ) );
    }
}, 999 );
```

Si les valeurs journalisées à cette priorité tardive correspondent déjà à un tri différent de celui affiché dans l'inspecteur, la modification a eu lieu avant, côté `pre_get_posts` à une priorité plus basse ou côté construction des arguments du bloc. Si elles correspondent au réglage attendu, le problème vient d'ailleurs, potentiellement d'un cache de requête qui sert un résultat plus ancien.

## Corriger sans casser les autres requêtes du site

La tentation est de retirer purement le filtre fautif, mais il a souvent été ajouté pour une bonne raison sur une autre requête du site. La correction propre consiste à restreindre sa portée, en vérifiant le contexte avant d'agir :

```
add_action( 'pre_get_posts', function( $query ) {
    if ( $query->get( 'post_type' ) !== 'produit' ) {
        return;
    }
    // logique de tri spécifique ici
} );
```

Ce garde-fou suffit dans la majorité des cas à laisser le bloc Query appliquer son propre tri sans interférence, tout en conservant le comportement voulu ailleurs sur le site.

## Prévention

Sur un site qui accumule les filtres de requête au fil du temps, une convention simple évite ce type de régression : tout filtre `pre_get_posts` ajouté par une extension ou par du code maison doit vérifier explicitement le contexte (type de contenu, `is_main_query()`, identifiant de bloc le cas échéant) avant de modifier quoi que ce soit. Un filtre sans condition finit toujours par s'appliquer à une requête qu'il n'était pas censé toucher.

## En résumé

Un tri ignoré dans le bloc Query n'est presque jamais un défaut du bloc : c'est le signe qu'un autre point du site intervient plus tard dans la chaîne de construction de la requête. Journaliser les arguments juste avant l'exécution permet de trancher en quelques minutes plutôt qu'en heures de suppositions.