WordPress 7.0 vient d’être publiée et, comme à chaque version majeure du cœur, la question se pose immédiatement pour les sites multilingues : quels changements touchent réellement les plugins de traduction, et lesquels ne sont que des évolutions éditoriales sans impact technique pour les développeurs de sites traduits ? Cet article se concentre exclusivement sur l’impact pour les développeurs de sites multilingues, sans reprendre les nouveautés éditoriales générales de la version, déjà largement couvertes ailleurs sur le web.
Trois zones de changement du cœur méritent une attention particulière du point de vue multilingue : l’évolution de l’API des blocs synchronisés, les ajustements de la couche de requêtes de traduction interne, et l’arrivée continue de l’Abilities API introduite en 6.9, désormais plus largement exploitée par le cœur lui-même.
Impact fort : l’évolution des blocs synchronisés (patterns)
WordPress 7.0 étend les capacités des motifs synchronisés (introduits en 6.6 sous le nom de « blocs synchronisés »), en permettant désormais une synchronisation partielle plus fine au niveau de certains attributs de bloc individuels, plutôt qu’au niveau du motif entier. Pour les sites multilingues, c’est un point sensible : un motif synchronisé partagé entre plusieurs langues doit pouvoir conserver une structure commune (mise en page, styles) tout en autorisant un contenu textuel différent par langue.
Avant cette version, un motif synchronisé posait un vrai dilemme aux plugins multilingues : soit tout le texte du motif était identique dans toutes les langues (ce qui n’a aucun sens éditorial), soit il fallait désynchroniser complètement le motif pour permettre sa traduction, perdant au passage l’intérêt de la synchronisation pour les mises à jour de mise en page. La synchronisation partielle par attribut change la donne, en théorie : un motif pourrait rester synchronisé sur sa structure visuelle tout en laissant le texte librement traduisible.
État de la compatibilité chez WPML et Polylang
À la date de publication de cet article, ni WPML ni Polylang n’ont annoncé de rupture de compatibilité majeure avec WordPress 7.0. Les deux éditeurs ont publié des notes de compatibilité confirmant un fonctionnement correct des mécanismes existants de traduction de blocs. En revanche, la prise en charge complète de la synchronisation partielle par attribut n’est pas encore native dans les interfaces de traduction : à ce stade, un motif utilisant cette nouvelle fonctionnalité continue d’être traité par les plugins multilingues comme un bloc classique, sans distinction fine entre attributs synchronisés et non synchronisés.
Concrètement, cela signifie qu’un développeur qui construit dès aujourd’hui des motifs exploitant la synchronisation partielle de WordPress 7.0 doit continuer à tester manuellement le comportement de traduction, sans attendre une prise en charge automatique et fine par son plugin multilingue habituel.
Impact modéré : les ajustements de la fonction wp_query et le chargement des traductions
WordPress 7.0 introduit des optimisations internes sur la mise en cache des requêtes de WP_Query, notamment pour réduire le nombre de requêtes SQL lors du chargement de contenus liés (taxonomies, métadonnées). Les plugins multilingues qui filtrent fortement les requêtes SQL pour restreindre les résultats à une langue donnée (via les hooks posts_join et posts_where, standards utilisés aussi bien par WPML que par Polylang) doivent vérifier que ces optimisations de cache ne contournent pas leurs filtres de langue dans certains contextes, en particulier les requêtes de type WP_Query avec le paramètre suppress_filters mal configuré.
Ce n’est pas une régression documentée à ce jour, mais un point de vigilance technique que nous recommandons de tester systématiquement lors de toute migration vers 7.0, en particulier sur des thèmes ou plugins qui construisent leurs propres requêtes personnalisées plutôt que de s’appuyer sur les fonctions de requête standard de WordPress.
Impact faible mais à surveiller : l’Abilities API et les intégrations IA
L’Abilities API, introduite en WordPress 6.9, continue de se développer en 7.0 avec de nouveaux points d’extension permettant à des outils d’intelligence artificielle d’interagir avec le contenu du site de façon structurée. Pour le multilingue, cela ouvre une question à surveiller dans les mois à venir : la manière dont ces capacités exposées aux agents IA prendront (ou non) en compte le contexte linguistique d’une requête. À ce stade, aucun standard n’est encore établi côté WPML ou Polylang pour exposer une capacité de traduction via l’Abilities API, mais le sujet est suivi de près par les deux éditeurs selon leurs communications publiques respectives.
Recommandations pratiques
- Mettre à jour WPML et Polylang vers leur dernière version avant toute migration vers WordPress 7.0, les correctifs de compatibilité continuant d’arriver au fil des semaines suivant une sortie majeure ;
- Tester manuellement tout motif synchronisé existant après migration, en particulier ceux utilisant des blocs de texte partagés entre langues ;
- Auditer les requêtes SQL personnalisées du thème ou de plugins maison qui filtrent par langue, pour vérifier leur compatibilité avec les nouvelles optimisations de cache de
WP_Query; - Différer la migration en production de deux à trois semaines après la sortie d’une version majeure, le temps que l’écosystème des plugins multilingues stabilise ses propres correctifs.
Notre verdict
WordPress 7.0 ne casse rien de fondamental pour les sites multilingues à ce jour, mais introduit des évolutions structurelles, en particulier sur les motifs synchronisés, qui méritent d’être suivies de près dans les prochains mois. La prudence habituelle reste de mise : tester sur un environnement de staging avant toute mise à jour en production, et ne pas se fier uniquement à l’absence d’erreur visible immédiate pour valider une compatibilité complète.
