WordPress 7.1 Beta 1 est disponible : calendrier et nouveautés

WordPress 7.1 Beta 1 est disponible depuis le 15 juillet 2026. Cette première version de test donne une vision plus concrète des nouveautés qui devraient accompagner la version finale, toujours programmée pour le 19 août 2026. Son périmètre est particulièrement riche, mais il peut encore évoluer au fil des prochaines bêtas et des versions candidates.

Comment tester WordPress 7.1 Beta 1 ?

Cette bêta est réservée aux tests et au développement. Elle ne doit pas être installée sur un site en production ou sur un environnement critique. Pour l’essayer, WordPress propose quatre possibilités :

• installer l’extension WordPress Beta Tester, puis choisir le canal « Bleeding edge » et le flux « Beta/RC Only » ;
• télécharger directement l’archive de WordPress 7.1 Beta 1 ;
• lancer la commande WP-CLI wp core update --version=7.1-beta1 ;
• utiliser WordPress Playground pour tester la version directement dans un navigateur.

Les anomalies peuvent être signalées dans la section Alpha/Beta des forums WordPress ou dans WordPress Trac lorsqu’elles peuvent être reproduites précisément.

Annonce officielle de WordPress 7.1 Beta 1. Scénarios officiels de test de WordPress 7.1.

Calendrier prévisionnel de sortie de WordPress 7.1

Source.

Fonctionnalités attendues dans WordPress 7.1

La feuille de route publiée par l’équipe Core le 19 juin 2026 confirme l’orientation générale de WordPress 7.1 : collaboration, personnalisation dans l’éditeur, médias, APIs et poursuite des fondations liées à l’IA. Comme toujours avec WordPress, cette feuille de route liste des travaux activement poursuivis, sans garantir que chaque élément sera forcément présent dans la version finale.

Intégration de React 19

L’équipe Core de WordPress prépare l’intégration de React 19 dans WordPress 7.1, une évolution qui concernera principalement Gutenberg et les interfaces d’administration modernes du CMS. La transition devait d’abord passer par le plugin Gutenberg, terrain d’expérimentation habituel des nouvelles fonctionnalités et mises à jour techniques.

Le calendrier vient toutefois de connaître un premier accroc. Après la publication de Gutenberg 23.3.0 avec React 19, l’équipe a constaté que de nombreux plugins conçus pour WordPress avec React 18 devenaient incompatibles et pouvaient provoquer des plantages. Le problème ne vient pas tant d’un changement massif d’API entre React 18 et React 19 que d’incompatibilités de runtime, notamment autour de react/jsx-runtime : des plugins embarquent leur propre version de cet helper, capable de générer des éléments que React 19 rejette ensuite.

WordPress a donc temporairement annulé la mise à niveau et publié ce retour à React 18 dans Gutenberg 23.3.2. L’objectif est de préparer une stratégie moins brutale, plus incrémentale, avec la possibilité de basculer entre React 18 et React 19 via un flag expérimental et une couche de compatibilité pour les plugins déjà publiés. L’équipe indique malgré tout rester engagée sur l’objectif d’une intégration dans WordPress 7.1.

Pour les développeurs de blocs et de plugins utilisant les packages @wordpress/*, le signal reste le même : il faut continuer à vérifier la compatibilité avec React 19, tout en gardant à l’esprit que la migration n’est pas encore stabilisée côté Gutenberg.

La roadmap du 19 juin maintient React 19 dans les travaux ciblés pour 7.1, mais confirme une trajectoire prudente : la mise à jour doit d’abord repasser par Gutenberg, avec un mode expérimental permettant aux développeurs de tester leurs extensions avant une intégration ultérieure dans le Core.

Source. Mise à jour du 5 juin 2026.

Le retour de la collaboration en temps réel (RTC) ?

Retirée de la version 7.0 en raison de problèmes techniques, la fonctionnalité de collaboration en temps réel (RTC) est toujours considérée comme stratégique pour l’avenir de WordPress. Après le travail de retrait pour la version 7.0, un nouveau plan doit être proposé afin d’organiser davantage de tests et poursuivre le développement pour une future version du CMS, potentiellement WordPress 7.1.

La roadmap officielle confirme que la collaboration en temps réel reste un axe majeur du cycle 7.1, mais elle ne tranche pas encore totalement la forme que prendra son intégration. Deux arbitrages restent importants : faut-il livrer une fonctionnalité visible complète dès 7.1 ou seulement une partie de l’architecture sous-jacente, et quel mécanisme de stockage retenir pour synchroniser les changements ?

Début juin, l’équipe WordPress a lancé une campagne de tests consacrée aux fonctionnalités d’édition collaborative prévues pour WordPress 7.1. Bien que le billet ne mentionne pas explicitement le retour de la collaboration en temps réel, cette initiative renforce l’idée que les travaux autour de la coédition restent une priorité pour les prochaines versions du CMS.

Autre volet plus concret : les Notes doivent progresser dans l’éditeur, avec des commentaires plus riches, des réactions emoji, des notifications, une expérience plus compacte, un mode suggestion et un mécanisme pour appliquer des suggestions. WordPress 7.1 pourrait donc poser les bases d’une collaboration plus réaliste dans l’éditeur, même si la coédition en direct reste dépendante des derniers choix techniques.

La bêta 1 permet déjà de tester plusieurs améliorations de la collaboration asynchrone. Les Notes acceptent le gras, l’italique, le code, les liens et les emoji, ainsi que les mentions @ pour interpeller un collaborateur. Il devient aussi possible d’ouvrir plusieurs conversations sur un même bloc, d’attacher une note à une sélection de texte et de replier les commentaires longs. L’annonce ne confirme en revanche pas le retour de la coédition en temps réel dans cette version.

Le traitement des médias côté client enfin dans le Core ?

Initialement prévu pour le Core de WordPress 7.0, le traitement des médias côté client a finalement été retiré durant le cycle de développement afin de réduire la portée de la version et de poursuivre sa maturation dans le plugin Gutenberg. La fonctionnalité permet notamment d’effectuer certaines opérations de traitement directement dans le navigateur, réduisant ainsi la charge sur le serveur.

Début juin, l’équipe WordPress a lancé un nouvel appel à tests consacré à cette fonctionnalité. La roadmap confirme que ce chantier est bien suivi pour WordPress 7.1, avec un périmètre plus large que le simple redimensionnement local des images : support HEIC, Ultra HDR, conversion GIF vers vidéo, reprise des téléversements après erreur ou perte de connexion, transcodage vidéo vers des formats compatibles web, optimisation de médias déjà envoyés et génération locale de poster pendant l’upload vidéo.

L’autre nouveauté média attendue est une modale d’édition dédiée. Elle remplacerait l’outil de recadrage inline actuel dans l’éditeur de blocs et regrouperait recadrage libre, ratios prédéfinis, rotation fine, retournement et édition des métadonnées. La roadmap mentionne aussi des améliorations de galerie, notamment pour la conversion des anciens shortcodes, les galeries dynamiques et l’accès aux images attachées à l’article en cours.

La bêta 1 permet de tester le traitement des médias dans le navigateur, avec la prise en charge des formats HEIC, Ultra HDR, AVIF et WebP, ainsi que la conversion des GIF en vidéo. Une barre de progression et des tentatives automatiques en cas de coupure doivent rendre les téléversements plus fiables. La nouvelle modale réunit le recadrage, la rotation et les métadonnées. La médiathèque gagne aussi le défilement infini par défaut, désactivable dans le profil utilisateur, tandis que l’outil d’insertion fait remonter les images attachées à l’article en cours dans une section dédiée.

Adresses e-mail Unicode

L’équipe Core de WordPress a également lancé un appel aux tests concernant la prise en charge des adresses e-mail Unicode, une évolution liée au ticket #31992 dont le support initial a été intégré dans la révision 62482. Si elle est retenue pour WordPress 7.1, cette fonctionnalité permettra notamment d’utiliser des adresses contenant des caractères non ASCII, comme grå@grå.org, à condition que la base de données du site utilise l’encodage utf8mb4. Les fonctions is_email() et sanitize_email() ont été adaptées en conséquence et la validation des adresses s’aligne désormais sur la spécification WHATWG utilisée par les navigateurs.

Cette évolution introduit également une nouvelle classe WP_Email_Address, destinée à faciliter la gestion des adresses Unicode par les thèmes et extensions. WordPress prévoit un mécanisme permettant de désactiver cette prise en charge si une intégration externe ne supporte pas encore les adresses Unicode.

La roadmap élargit le sujet au-delà des seuls e-mails : WordPress 7.1 vise aussi une meilleure prise en charge Unicode pour les noms d’utilisateur et les slugs, afin de mieux couvrir les usages internationaux.

Styles responsive et pseudo-états dans l’éditeur

WordPress 7.1 devrait aussi faire avancer deux demandes anciennes de l’édition full-site : la personnalisation responsive et les styles d’état. L’objectif est de permettre de définir, directement dans l’éditeur, l’apparence d’un bloc selon la taille d’écran ou selon son état d’interaction, par exemple hover, focus ou active, sans repasser systématiquement par du CSS personnalisé.

Ces réglages seraient disponibles à la fois dans les styles globaux et au niveau d’une instance de bloc. La roadmap mentionne également des points de rupture configurables par les thèmes via theme.json, ce qui donnerait aux créateurs de thèmes un contrôle plus fin sur les vues mobile, tablette et desktop.

Un appel à tests publié le 3 juillet 2026 donne une idée plus concrète de l’expérience visée : modifier certains styles depuis les vues tablette ou mobile de l’éditeur, avec un comportement pensé d’abord comme une évolution progressive de l’éditeur plutôt que comme un nouveau système complet.

L’éditeur devrait aussi mieux afficher les styles hérités. L’objectif est de rendre plus lisible l’origine d’un réglage appliqué à un bloc : thème, styles globaux, parent ou personnalisation locale.

Ces deux grandes fonctions sont proposées au test dans la bêta 1. Les styles responsive peuvent être définis dans les styles globaux comme sur un bloc individuel, et les auteurs de thèmes peuvent déclarer leurs propres points de rupture dans theme.json. Les états interactifs disposent également de contrôles standardisés pour personnaliser notamment l’apparence au survol ou au focus.

Nouveaux blocs et améliorations de l’éditeur

La feuille de route cite plusieurs blocs prévus ou en cours de finalisation pour 7.1 : un bloc Playlist, un bloc Table des matières et un bloc Tabs. D’autres améliorations concernent les blocs existants, comme le lightbox de galerie, le support de contenus éditables dans le bloc HTML, un réglage permettant de marquer une image comme décorative pour les lecteurs d’écran, ou encore de meilleures conversions depuis les shortcodes.

Dans la bêta 1, WordPress propose de tester les blocs Playlist et Tabs. Playlist permet de réunir plusieurs fichiers audio avec une visualisation facultative de leur forme d’onde, tandis que Tabs organise un contenu dans des panneaux accessibles par onglets. Le bloc HTML accepte maintenant des blocs imbriqués éditables et le bloc Image propose une option pour déclarer une image décorative aux technologies d’assistance. Les images et dégradés d’arrière-plan peuvent également se superposer sur plusieurs blocs, notamment Groupe, Citation, Accordéon et Contenu de la publication.

WordPress 7.1 ne masquera finalement pas le bloc Classic dans l’outil d’insertion. Après une première annonce indiquant que le bloc core/freeform serait retiré par défaut de l’inserter, de la bibliothèque de blocs et des commandes précédées d’une barre oblique, l’équipe Core a fait marche arrière le 7 juillet 2026. Le bloc Classic restera donc disponible par défaut dans WordPress 7.1, sans changement de comportement pour les utilisateurs ou les développeurs.

Cette décision supprime aussi le filtre wp_classic_block_supports_inserter, qui n’aura jamais été livré dans une version stable, ainsi que le message de migration prévu au niveau du bloc. Le plugin compagnon “Enable Classic Block” doit être fermé, puisqu’il n’a plus d’utilité avec le comportement par défaut restauré. L’effort se déplace plutôt vers une meilleure conversion des contenus Classic vers des blocs, des mécanismes de migration plus fiables, et une gestion plus fine du chargement de TinyMCE à terme.

APIs, identité du site et administration

WordPress 7.1 poursuit également plusieurs chantiers d’infrastructure. L’Abilities API doit exposer de manière plus structurée ce qu’un site peut faire, notamment pour les outils d’IA. Une proposition publiée le 2 juillet 2026 envisage d’ajouter trois capacités de lecture dans le Core : réglages, contenus et utilisateurs. Les Block Bindings doivent s’étendre aux éléments de liste et aux blocs imbriqués. L’éditeur de publication devrait aussi continuer sa transition vers un fonctionnement systématique en iframe, d’abord pour les thèmes basés sur les blocs.

Dans la bêta 1, l’iframe est généralisée à l’éditeur de publication afin d’isoler la zone d’édition des styles de l’administration. Les développeurs doivent donc vérifier leurs extensions, en particulier les blocs qui utilisent encore la version 2 ou une version antérieure de la Block API, et les mettre à jour vers la version 3. Les Block Bindings sont par ailleurs étendus aux éléments de liste, et de nouvelles fonctions permettent aux thèmes et extensions d’enregistrer leurs propres icônes pour le bloc Icons.

Côté administration, WordPress 7.1 doit rendre la navigation plus cohérente entre les écrans classiques et les éditeurs. La barre d’administration restera visible par défaut dans l’éditeur de publication et l’éditeur de site, sauf en mode sans distraction. Le logo WordPress ou l’icône du site ne servira plus de bouton de retour : un chevron remplira désormais cette fonction. Le logo WordPress ouvrira la page À propos, tandis que l’icône du site donnera accès au menu du site. Son titre restera également visible pendant l’édition.

Ce changement peut avoir un effet sur les extensions qui ajoutent des éléments à la barre d’administration. Leurs développeurs sont invités à vérifier leur affichage dans l’éditeur de site, où la présence permanente de cette barre constitue un nouveau comportement.

La roadmap annonce par ailleurs une palette de commandes mieux organisée, une nouvelle section Design → Identity pour gérer le logo, le favicon, le titre et le slogan du site, ainsi qu’un widget de tableau de bord “On This Day” permettant de faire remonter d’anciens contenus. Elle prévoit aussi que l’éditeur de site reflète mieux le jeu de couleurs choisi dans l’administration.

Ces changements sont proposés au test dans la bêta 1. Les résultats de la palette de commandes sont regroupés entre éléments récents, correspondances et suggestions. La liste des publications affiche désormais un extrait, l’historique des révisions visuelles distingue plus clairement les sauvegardes automatiques et l’écran de modification d’un commentaire permet de corriger son commentaire parent, à condition qu’il appartienne à la même publication.

Une proposition publiée le 7 juillet ajoute à ce chantier les premières fondations d’un système de design commun pour l’administration. Le périmètre envisagé pour WordPress 7.1 reste technique : des design tokens exposés sous forme de variables CSS dans une feuille de style wp-theme, ainsi qu’un composant React ThemeProvider. L’objectif est d’aider le Core et les extensions à construire des interfaces plus cohérentes et accessibles, pas de livrer dès cette version une refonte complète de l’administration.

IA : Guidelines, connecteurs et AI Client

La partie IA de WordPress 7.1 vise surtout les fondations techniques sur lesquelles les extensions pourront s’appuyer. L’AI Client doit permettre aux plugins de déclencher des usages IA depuis WordPress de façon plus standardisée. Pour ce cycle, la roadmap cite deux capacités en particulier : le streaming de génération, pour recevoir une réponse progressivement, et les embeddings, pour représenter les contenus sous forme de vecteurs et faciliter des recherches par similarité.

Les connecteurs doivent aussi évoluer. Introduits pour enregistrer et gérer des connexions à des services externes, ils devraient dépasser le simple modèle de clé API, avec un premier support de l’authentification par nom d’utilisateur et mot de passe d’application. WordPress explore aussi des formulaires de connexion plus déclaratifs, par exemple pour saisir une URL ou choisir un modèle par défaut.

La nouveauté la plus éditoriale est le projet Guidelines : un espace permettant de définir des règles de rédaction, de ton, de marque, d’utilisation des images ou propres à certains blocs. Ces consignes seraient enregistrées directement dans WordPress afin de pouvoir être consultées par les rédacteurs, les extensions et les outils d’IA, plutôt que répétées à chaque interaction.

Une proposition d’intégration publiée le 22 juin 2026 précise désormais l’architecture envisagée pour WordPress 7.1. Guidelines s’appuierait sur un nouveau type de contenu interne nommé wp_knowledge, conçu comme un espace commun pour stocker les connaissances liées au site. Trois types de contenus seraient fournis dans le Core : guideline pour les consignes, memory pour les informations durables explicitement enregistrées et note pour les notes de travail privées.

Cette fondation bénéficierait des mécanismes habituels de WordPress, notamment les révisions, les rôles et permissions ainsi qu’un accès par l’API REST. Une page Réglages → Guidelines permettrait de gérer les consignes par périmètre, par exemple pour l’ensemble du site, les textes, les images ou les blocs. Le système resterait extensible afin que les plugins puissent ajouter leurs propres types de connaissances ou catégories de consignes.

Le périmètre proposé reste volontairement limité au stockage et à l’accès aux informations : WordPress 7.1 n’intégrerait ni fournisseur d’IA, ni modèle, ni système autonome de mémoire ou de recherche. La proposition doit encore être examinée avant son éventuelle intégration définitive au Core, tandis que des fonctions plus avancées, comme les skills, sont déjà renvoyées vers une version ultérieure.

Performance

Le principal changement de performance évoqué concerne le chargement spéculatif. Sur les sites disposant à la fois d’un cache objet et d’un cache de page, WordPress pourrait passer d’un comportement prudent à un mode plus actif, afin de précharger ou pré-rendre davantage de pages et rendre la navigation plus rapide.

Deux plugins de performance restent également dans le radar du cycle : View Transitions, pour les transitions animées côté front, et Enhanced Responsive Images, qui cherche à calculer des valeurs sizes plus précises dans les thèmes basés sur les blocs.

Source : Roadmap to 7.1.