WordPress 7.1 : ce que la mise à jour change pour les thèmes et les développeurs

Une version 7.1 attendue le 19 août 2026

WordPress 7.1 est programmée pour le 19 août 2026, soit le dernier jour de WordCamp US, organisé à Phoenix du 16 au 19 août. Cette échéance reste une date planifiée : elle situe la sortie dans le calendrier du projet, sans constituer une garantie que le paquet sera publié sans modification du planning.

Cette nouvelle version arrive après deux mises à jour de la branche 7.0. WordPress 7.0.2 a été publiée le 17 juillet 2026 pour corriger une vulnérabilité critique et une autre de gravité élevée. WordPress 7.0.3 a suivi le 6 août avec douze correctifs supplémentaires. Pour les équipes qui maintiennent des sites en production, cette séquence rappelle qu’une mise à niveau majeure ne doit pas faire oublier les versions de maintenance et leurs correctifs de sécurité.

Le responsive devient configurable au niveau des blocs

Le changement le plus visible pour les créateurs de thèmes concerne les styles responsifs des blocs. WordPress 7.1 permet désormais de définir des styles distincts pour les affichages mobile et tablette, à la fois dans les Styles globaux associés à un type de bloc et sur une instance individuelle dans l’éditeur.

Les points de rupture fournis par défaut sont fixés à 480px pour le mobile et 782px pour la tablette. Les thèmes ne sont toutefois pas limités à ces valeurs : ils peuvent configurer leurs propres seuils au moyen de la propriété de niveau supérieur settings.viewport dans theme.json.

En pratique, cette évolution réduit le besoin de contourner l’interface avec des règles CSS spécifiques lorsque le comportement attendu varie selon la taille d’écran. Elle donne aussi aux auteurs de thèmes un emplacement déclaré et partagé pour leurs seuils responsifs. Les développeurs devront néanmoins vérifier le rendu des blocs existants, en particulier lorsque des styles globaux et des réglages appliqués à une instance se combinent.

États interactifs et styles de fond

WordPress 7.1 prend également en charge plusieurs pseudo-états dans theme.json et dans l’éditeur : :hover, :focus, :focus-visible et :active. Cette possibilité concerne pour l’instant uniquement les blocs Button et Navigation Link. Elle fournit donc un cadre plus direct pour déclarer les états d’interaction de ces éléments, mais ne constitue pas encore un mécanisme généralisé à tous les blocs.

Deux nouvelles capacités de support complètent ce travail. Le support background.gradient permet au moteur de style de produire un dégradé avec une image d’arrière-plan au moyen de la propriété CSS abrégée background-image, sous la forme de valeurs séparées par des virgules. WordPress 7.1 ajoute aussi dimensions.minWidth. Ce support applique une largeur minimale via min-width et peut utiliser les préréglages dimensionSizes lorsqu’un thème en fournit.

Une API publique pour les icônes SVG

L’API des icônes SVG devient une véritable API publique dans WordPress 7.1. Les extensions et les thèmes peuvent enregistrer des collections et des icônes, puis les récupérer à l’aide de wp_register_icon_collection(), wp_register_icon() et wp_get_icon().

Pour les développeurs, l’intérêt principal est de disposer d’un point d’intégration prévu par WordPress plutôt que de maintenir chacun son propre mécanisme de déclaration et de récupération d’icônes. Le périmètre exact de cette API devra toutefois être pris en compte dans les projets qui ciblent plusieurs versions de WordPress : la disponibilité de ces fonctions dépendra de la version exécutée.

L’éditeur d’articles sera toujours chargé dans une iframe

Avec WordPress 7.1, l’éditeur d’articles devient systématiquement chargé dans une iframe. Cette règle s’applique quel que soit le type de thème, la version de l’API des blocs enregistrés ou la version d’API des blocs présents dans le contenu.

Ce fonctionnement uniformise le contexte d’exécution de l’éditeur. Il peut cependant avoir des conséquences pour les extensions qui ajoutent des scripts, des styles ou des composants destinés à l’édition des articles. Les intégrations doivent être testées dans ce contexte désormais généralisé, au lieu de supposer que le code s’exécute toujours dans le document principal de l’administration.

Des ajustements pour l’administration et la maintenance du code

Plusieurs changements ciblent la qualité technique de l’administration. Dans les tableaux de listes d’articles, la cellule d’en-tête de ligne principale th a été déplacée de la colonne des cases à cocher vers celle du titre dans le changeset 62838. Cette modification concerne notamment la structure sémantique et l’interprétation des tableaux par les technologies d’assistance.

La propriété __next40pxDefaultSize devient sans effet dans WordPress 7.1. Introduite dans la version 6.7 puis déclarée progressivement obsolète dans la 6.8, elle ne doit plus être considérée comme un levier fonctionnel dans les composants concernés. Les interfaces d’administration disposent par ailleurs de deux fonctions supplémentaires, wp_get_tooltip() et wp_get_toggletip(), destinées à combler le manque d’outils dédiés aux infobulles et aux toggletips.

Sur le socle JavaScript, WordPress 7.1 n’intègre pas React 19 et reste sur React 18.3. Les extensions ne doivent donc pas supposer que la mise à jour fournit la nouvelle version majeure de React.

Gutenberg, normes de code et Playground

Du côté de Gutenberg 23.6, les blocs Playlist et Tabs ont été stabilisés. Le bloc Tabs bénéficie également de boutons dans la barre d’outils pour réordonner les onglets. Cette stabilisation constitue un signal utile pour les projets qui hésitaient à s’appuyer sur ces blocs, mais elle ne dispense pas de vérifier la compatibilité des contenus et des extensions qui les personnalisent.

Les outils de développement évoluent aussi. L’API Site Manager de WordPress Playground permet de créer, lister, modifier et supprimer des sites Playground directement depuis du code, sans passer par l’interface. Elle ouvre la voie à des scénarios automatisés pour préparer et gérer des environnements de test, selon les besoins des équipes.

Enfin, WordPress Coding Standards 3.4.0 est une version fonctionnelle, tandis que la 3.4.1 inclut un correctif de sécurité. Les projets qui utilisent ces standards doivent donc traiter la 3.4.1 comme une mise à niveau prioritaire plutôt que comme une simple révision de confort.

Ce que les équipes doivent préparer

Pour les développeurs de thèmes, le travail prioritaire consiste à examiner les déclarations de theme.json, à décider si les seuils de settings.viewport doivent être personnalisés et à tester les états :focus et :focus-visible sur les boutons et les liens de navigation. Les extensions qui manipulent l’éditeur doivent, elles, valider leur comportement dans une iframe systématique.

Les mainteneurs peuvent également rechercher les usages de __next40pxDefaultSize, évaluer les dépendances à React et vérifier les éventuelles implémentations internes d’icônes SVG avant d’adopter l’API publique. Enfin, les mises à jour 7.0.2 et 7.0.3 montrent qu’il est préférable de maintenir les installations à jour avant l’arrivée de WordPress 7.1, plutôt que d’attendre la version majeure pour traiter les correctifs disponibles.

À retenir

• WordPress 7.1 est programmée pour le 19 août 2026, après les versions 7.0.2 et 7.0.3 publiées en juillet et août.
• Les styles responsifs des blocs prennent en charge les vues mobile et tablette, avec des seuils par défaut de 480 px et 782 px configurables dans theme.json.
• Les pseudo-états sont disponibles pour les blocs Button et Navigation Link, tandis que l’API des icônes SVG devient publique.
• L’éditeur d’articles sera toujours chargé dans une iframe et WordPress 7.1 restera basé sur React 18.3.
• Les équipes doivent tester leurs extensions, leurs thèmes et leurs outils d’administration avant la migration.

Sources

• What’s new for developers? (August 2026) — developer.wordpress.org, 10 August 2026