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éécritorderbysans 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
inheritactivé 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
querypartiellement é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.
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.
