Suivre les tickets Trac plutôt qu’attendre le changelog officiel, c’est la seule manière de ne pas être pris au dépourvu quand une version majeure change le rendu d’un bloc aussi central que le bloc Requête. En ce début d’année 2024, plusieurs discussions sur make.wordpress.org autour de la prochaine version majeure portent justement sur la manière dont ce bloc génère ses liens de pagination et ses attributs de filtrage, avec un effet direct sur l’indexation des listes d’articles.
Rien n’est figé à ce stade : les tickets évoluent, certains changements proposés seront reportés, d’autres ajustés avant la sortie finale. Mais pour un développeur qui exploite le bloc Requête pour générer des pages de catégorie personnalisées ou des listes filtrées, il est plus sain d’anticiper la direction prise que de découvrir un changement de comportement le jour de la mise à jour en production.
Ce qui est en discussion sur le rendu des liens
Le point central concerne la génération des liens de pagination à l’intérieur du bloc Requête lorsqu’il est combiné à des filtres côté client. Aujourd’hui, chaque combinaison de filtres visibles dans l’interface peut produire une URL distincte si le thème l’implémente naïvement, ce qui multiplie les variantes d’une même liste sans valeur ajoutée pour l’indexation. Les discussions en cours visent à mieux standardiser la façon dont ces variantes sont marquées, potentiellement via un attribut canonique plus cohérent porté par le bloc lui-même plutôt que laissé à la charge du thème.
Concrètement, cela toucherait la sortie HTML du bloc core/query-pagination et la manière dont les paramètres de requête sont reflétés dans l’URL affichée. Un développeur qui a construit des filtres personnalisés au-dessus du bloc Requête avec du JavaScript côté client a donc intérêt à revérifier, dès la sortie de la version stable, que ses URLs générées restent cohérentes avec la balise canonique produite par son thème ou son extension SEO.
Pourquoi cela concerne l’indexation, pas seulement l’affichage
Le bloc Requête est aujourd’hui l’un des mécanismes les plus utilisés pour générer des listes d’articles côté thème de blocs (FSE), notamment sur les pages d’archive personnalisées. Chaque variante d’URL non maîtrisée devient une page potentiellement explorée par Googlebot, avec un contenu quasi identique à la page de référence. Sur un site à fort volume de contenu, cela peut représenter plusieurs milliers d’URLs parasites générées automatiquement, sans qu’aucun rédacteur n’ait rien publié de nouveau.
Voici ce qu’il convient de vérifier une fois la version stable disponible :
- La balise canonique générée sur les pages de résultats filtrés pointe-t-elle vers la page de liste non filtrée ?
- Les liens de pagination générés par le bloc restent-ils cohérents avec
rel="next"etrel="prev"si le thème les implémente encore ? - Les filtres côté client modifient-ils l’URL visible du navigateur, ou seulement l’affichage sans changement d’URL ?
Ce que ce changement ne traite pas
Il est important de ne pas confondre cette évolution du rendu avec les antipatterns de boucles de maillage automatique parfois construites au-dessus du bloc Requête, où un article s’auto-référence dans sa propre liste d’articles liés. Ce sujet, traité séparément, relève d’une erreur de configuration des requêtes plutôt que d’un changement de version : aucune mise à jour de WordPress ne corrige une boucle mal configurée par un intégrateur.
Une vérification simple avant mise à jour
Sur un environnement de test, comparer le HTML généré par une page utilisant le bloc Requête avant et après mise à jour permet de repérer rapidement un changement de structure :
wp eval 'echo do_shortcode("[block id=\"liste-articles\"]");' > avant.html
# après mise à jour de l'environnement de test
wp eval 'echo do_shortcode("[block id=\"liste-articles\"]");' > apres.html
diff avant.html apres.htmlRester pragmatique face à un changement encore instable
Un ticket Trac ouvert n’est pas un engagement définitif. La bonne pratique consiste à documenter dans un tableau de suivi interne les tickets qui touchent des blocs utilisés en production, sans modifier son code en anticipation d’un comportement qui pourrait encore changer avant la version finale. Le vrai travail commence à la sortie de la release candidate, moment où le comportement est suffisamment stabilisé pour justifier des tests approfondis sur un environnement de préproduction.
En résumé
La prochaine version majeure de WordPress s’annonce comme un point de vigilance pour tous les sites qui s’appuient fortement sur le bloc Requête pour générer des listes filtrées. Le sujet mérite un suivi actif des tickets Trac, une vérification systématique de la balise canonique sur les pages générées, et une distinction claire avec les problèmes de boucles de maillage qui relèvent, eux, d’une erreur d’implémentation indépendante de la version du cœur.
