WordPress 7.1 : les nouveautés, et ce qui a encore été retiré

Trois mois après la 7.0, voilà la deuxième version majeure de 2026. Je l’ai suivie depuis sa troisième version candidate sur un de mes WordPress de test, en comparant son cœur à celui de la 7.0.4 installée juste à côté, plutôt que de recopier le communiqué.

Bien m’en a pris. Entre ce que j’ai relevé le 15 août et ce qui a été publié le 19, il manque quelque chose d’assez énorme.

Une version WordPress, ça ne se juge pas qu’à la liste des nouveautés. Ça se juge aussi à ce qui a disparu entre l’annonce et la sortie. On l’a vu avec la version 7. La 7.1 vient de le confirmer d’une façon spectaculaire, et je peux cette fois le prouver fichier par fichier.

Qu’est-ce que WordPress 7.1 apporte vraiment ?

En mai, quand la 7.0 est sortie, j’avais listé trois chantiers repoussés à la 7.1 : l’éditeur en iframe permanent, le traitement des médias côté navigateur, et la fameuse co-édition en temps réel. Trois mois plus tard, on peut faire les comptes. Deux sur trois, et le troisième est reparti en arrière.

Côté volume, le guide officiel des changements techniques annonce 310 tickets résolus sur Trac, dont 100 évolutions ou nouvelles fonctionnalités et plus de 180 correctifs de bogues. Sur ce total, 46 correctifs visent l’accessibilité du CMS, 40 son interface et 28 l’administration. S’y ajoutent 600 améliorations côté éditeur. C’est une vraie version, pas un correctif déguisé.

L’éditeur en iframe : promesse tenue

La bascule est terminée. Tous les sites passent l’éditeur dans une iframe, y compris ceux qui trimballent encore des boîtes méta à l’ancienne. C’était le dernier verrou, il saute.

Concrètement, ça veut dire qu’un bout de JavaScript ou de CSS qui allait taper en dehors du document de l’éditeur ne le peut plus. Si vous avez du code maison dans un thème enfant, ou une extension un peu ancienne qui bricole l’éditeur, c’est exactement là que ça va coincer.

Est-ce que ça va casser votre site ? Non. Ça peut casser votre écran d’édition, ce qui est déjà bien assez pénible quand on découvre le problème un lundi matin avec un article à publier. Rien de dramatique, mais c’est à vérifier avant, pas après.

Les médias traités dans le navigateur : tenue, et même au-delà

Là, WordPress est allé plus loin que ce qui était annoncé. La compression, le redimensionnement et la génération des vignettes se font désormais dans le navigateur, avant l’envoi. Conséquence directe et très concrète : un envoi d’image ne se heurte plus à la limite de mémoire de PHP, et ne fait plus expirer la requête sur un mutualisé.

En fouillant les fichiers du cœur, je suis tombé sur deux modules dont le guide de sortie ne souffle mot. Dans wp-includes/js/dist/script-modules/ : un worker vips de 13 417 612 octets, soit 13,4 Mo, et un worker de conversion vidéo de 409 786 octets. Oui, vous avez bien lu : WordPress embarque de quoi convertir de la vidéo côté navigateur.

Ce n’est pas une supposition de ma part sur ce que contient ce fichier de 13,4 Mo. Le cœur le documente lui-même : dans wp-includes/script-modules.php, un commentaire précise que ces deux fichiers sont toujours livrés minifiés, et explique pourquoi.

the non-minified versions are not shipped because they consist
of large inlined WASM/worker code with no debugging value.

Du WebAssembly embarqué en dur, donc. Il s’agit de libvips, une bibliothèque de traitement d’images bien connue côté serveur, compilée cette fois pour tourner dans le navigateur.

Le bénéfice est réel pour qui gère des sites avec beaucoup de contenu visuel : le serveur ne fait plus le gros du travail. C’est la machine du rédacteur qui encaisse. Sur un mutualisé, ça change la vie.

Le recadrage des images passe enfin dans un vrai atelier

Dans la foulée, l’ancien outil de recadrage intégré à la volée laisse la place à une fenêtre dédiée. Recadrage libre ou au format imposé, retournement, rotation précise et modification des métadonnées se retrouvent au même endroit, dans un seul parcours.

Le bouton Recadrer que vous connaissez ouvre maintenant cette fenêtre. C’est le genre de changement dont personne ne parle et qui fait gagner du temps tous les jours : jusqu’ici, redresser une photo de deux degrés puis corriger son texte alternatif demandait deux passages à deux endroits différents.

Que s’est-il passé avec la co-édition en temps réel ?

Et c’est là que ça devient intéressant. Accrochez-vous, parce que je n’avais encore jamais vu ça d’aussi près.

Le 15 août, sur la troisième version candidate, j’ai trouvé un paquet JavaScript qui n’existait pas en 7.0.4 : wp-includes/js/dist/sync.min.js, 132 275 octets. Et il n’était pas posé là au hasard. Dans le manifeste des scripts, le handle wp-sync était déclaré comme dépendance de core-data, le paquet qui alimente les données de l’éditeur. Autrement dit, il était chargé dès qu’on ouvrait l’éditeur de blocs. Je l’avais vérifié sur les requêtes réseau, pas seulement dans le manifeste.

Dans la console du navigateur, l’objet window.wp.sync existait et exposait exactement quatre choses :

> Object.keys( window.wp.sync )
[ "Awareness", "Y", "YJS_VERSION", "privateApis" ]

> window.wp.sync.YJS_VERSION
"13"

Y, c’est la bibliothèque Yjs elle-même, avec ses structures de données répliquées sans conflit. Awareness, c’est le protocole qui gère la présence : qui est connecté, où se trouve son curseur. Le moteur de la co-édition, livré et chargé chez tout le monde, mais sans aucune interface pour le piloter.

J’avais écrit que le robinet était fermé mais la plomberie posée, et que ça ne durerait pas. Ça n’a pas duré quatre jours.

Dans la 7.1 publiée le 19 août, il n’y a plus rien. Pas de sync.min.js. Pas de handle wp-sync dans le manifeste. Pas d’objet window.wp.sync. Et côté PHP, tout le dossier wp-includes/collaboration/ a disparu avec ses trois classes, dont un serveur de synchronisation par sondage HTTP et un stockage des données dans les métadonnées des publications.

Ce n’est pas une lecture personnelle des fichiers. La page officielle de la version 7.1 les range noir sur blanc dans sa rubrique des fichiers supprimés :

Deleted files
  wp-includes/collaboration.php
  wp-includes/collaboration/class-wp-http-polling-sync-server.php
  wp-includes/collaboration/class-wp-sync-post-meta-storage.php
  wp-includes/collaboration/interface-wp-sync-storage.php
  wp-includes/js/dist/sync.js
  wp-includes/js/dist/sync.min.js

Le détail qui donne la mesure de la chose : sur les 261 fichiers supprimés par cette version, quatre seulement sont des fichiers PHP, et ce sont exactement ces quatre-là. Tout le reste, ce sont des icônes et du JavaScript. La 7.1 n’a retiré qu’une seule fonctionnalité du cœur, et c’est celle-ci.

Une version WordPress ne se juge pas qu’à la liste des nouveautés. Elle se juge aussi à ce qui a disparu entre l’annonce et la sortie.

Fabrice Ducarme, formateur WordPress

Ça en dit long sur la méthode. Du code jugé assez mûr pour être embarqué chez près de quatre sites sur dix dans le monde, puis retiré quatre jours avant la sortie. Je ne suis pas concerné personnellement, j’écris seul sur WPFormation… mais pour une rédaction avec beaucoup d’auteurs, ça fait la troisième version majeure d’attente. Et ces gens-là patientent depuis trois ans.

Alors comment travaille-t-on à plusieurs ?

Par la porte d’à côté, et c’est la vraie nouvelle de cette version pour les équipes. WordPress a retiré l’édition simultanée, mais il a nettement musclé l’annotation. Les notes déposées dans un contenu acceptent maintenant le texte enrichi et, surtout, les mentions.

Vous tapez @ dans une note, la liste des personnes du site apparaît, vous en désignez une, elle reçoit une notification par courriel. On peut mettre du gras, de l’italique, du code et des liens dans une note, et l’accrocher à un passage précis du texte plutôt qu’au bloc entier.

Le mécanisme est visible dans le code de l’éditeur, où l’auto-complétion s’appelle note-mentions et se déclenche sur le préfixe @ ; la mention insérée porte la classe wp-note-mention. Les champs de saisie proposent d’ajouter une note ou une mention, et de répondre à une note existante. Rien de tout cela n’existe en 7.0.4 : le mot "mention" est absent du fichier de l’éditeur.

Est-ce que ça remplace la co-édition ? Non, et il ne faut pas le vendre comme ça. Écrire à deux dans le même paragraphe en même temps, ça n’existe toujours pas. Mais relire, commenter, demander une correction à quelqu’un et le notifier, ça oui, et c’est l’essentiel de ce que font réellement les rédactions que j’accompagne. La collaboration asynchrone avance pendant que la synchrone recule.

Peut-on enfin faire du responsive sans écrire de CSS ?

Oui, et c’est le chantier le plus structurant de la version, même s’il fait moins de bruit que les blocs. WordPress 7.1 introduit un mécanisme unique pour dire à un bloc comment se comporter selon la taille de l’écran et selon son état.

Le fichier qui porte tout ça est nouveau : wp-includes/block-supports/states.php. Sa documentation interne annonce la couleur, en décrivant à la fois les pseudo-états et les états responsive.

including pseudo-states (e.g., `style[':hover']`) and responsive states
(e.g., `style['@mobile']` and `style['@mobile'][':hover']`).

Lisez bien la dernière forme : le survol sur mobile uniquement. Le même moteur traite les deux dimensions, et on peut les combiner. Concrètement, vous réglez dans l’éditeur l’apparence d’un bouton au survol, au focus clavier et à l’activation, sans une ligne de CSS. Le focus clavier géré nativement, pour l’accessibilité, c’est une vraie avancée.

Deuxième volet : les points de rupture deviennent les vôtres. Jusqu’ici vous subissiez ceux de WordPress, désormais vous les définissez dans le fichier theme.json de votre thème, et le responsive comme la visibilité des blocs suivent vos valeurs. Les valeurs par défaut du cœur sont 480 pixels pour le mobile et 782 pixels pour la tablette.

Pour mesurer l’ampleur du chantier : le mot "breakpoint" n’apparaît pas une seule fois dans la classe qui traite theme.json en 7.0.4. En 7.1, il y figure 159 fois.

Quels sont les deux nouveaux blocs de WordPress 7.1 ?

Curieusement, le guide des changements techniques ne les mentionne pas. Ils sont pourtant bien là, et pour vous qui écrivez, c’est probablement la nouveauté la plus visible.

Le dossier wp-includes/blocks passe de 109 à 115 blocs entre la 7.0.4 et la 7.1. Six entrées de plus, qui forment deux blocs utilisables : les quatre autres sont leurs blocs enfants, non insérables seuls.

Le bloc Onglets

Rangé dans la catégorie Design. Vous ajoutez le bloc, vous créez vos onglets, vous mettez ce que vous voulez dedans. Fini les extensions tierces pour un besoin aussi banal !

Il traînait à l’état expérimental depuis un moment. Il a été stabilisé dans Gutenberg 23.6, et il y a gagné au passage des boutons de réorganisation des onglets directement dans la barre d’outils. Si vous éditez des thèmes et que vous aviez renoncé à le styler tant que son balisage bougeait, c’est le moment de vous y remettre.

Petite précision pour ceux qui ont testé la version candidate : le bloc s’y appelait encore Tabs et taper "onglet" dans l’inséreur ne renvoyait rien. C’est réglé, la traduction française de la 7.1 le nomme bien Onglets.

Le bloc Liste de lecture

Catégorie Média, avec un bloc enfant par piste. C’est le retour d’une vieille connaissance : la fonction wp_playlist_shortcode() a été introduite dans WordPress 3.9, en avril 2014, dont l’une des nouveautés annoncées était justement de présenter de la musique et des extraits sous forme de listes de lecture. Douze ans plus tard, la fonction est toujours dans le cœur de la 7.1… et elle a enfin droit à son bloc.

Et il est nettement plus riche que l’ancien code court. En regardant sa configuration, on trouve une visualisation en forme d’onde avec six styles au choix (barres, miroir, ligne, blocs, points, ou barre de lecture), sa couleur et son dégradé, ceux de son arrière-plan, plus les habituels réglages d’affichage : liste des pistes, pochettes, noms des artistes, numéros, durées. De quoi présenter un podcast ou une discographie sans installer quoi que ce soit.

Pourquoi le guide technique n’en parle-t-il pas ? Parce que ces deux blocs ne viennent pas du cœur mais du projet Gutenberg, où ils ont été stabilisés après une longue période expérimentale. Le guide recense surtout les tickets Trac et ce qui casse ; deux blocs qui apparaissent dans l’inséreur ne cassent rien, donc ils passent entre les mailles.

Pourquoi la médiathèque défile-t-elle à l’infini ?

Voilà le point qui va faire grincer, et il faut saluer le projet WordPress de le documenter lui-même comme une régression connue.

La même version qui livre 46 correctifs d’accessibilité réintroduit un problème d’accessibilité connu. Le défilement infini revient par défaut dans la médiathèque en mode grille, à la place du bouton "Charger plus". Pour qui navigue au clavier ou au lecteur d’écran, une liste qui s’allonge toute seule sans point d’arrêt, c’est un piège.

Le changement est assumé noir sur blanc dans le code du cœur. Dans le fichier wp-includes/media.php, le commentaire de documentation du filtre concerné indique, en anglais dans le texte :

@since 7.1.0 Changed default to `true` and introduced
              per-user opt-out of infinite scrolling.

Traduit : depuis la 7.1.0, la valeur par défaut passe à "vrai", avec l’ajout d’une désactivation au cas par cas pour chaque compte. Le même bloc de documentation précise qu’un filtre posé par un thème ou une extension l’emporte sur la préférence individuelle.

Comment revenir à une médiathèque paginée ?

Trois solutions, de la plus simple à la plus technique.

1. Pour vous seul : allez dans Comptes > Profil, section Options personnelles. Une case à cocher désactive le défilement infini de la médiathèque. Le réglage est propre à chaque compte.
2. Pour tout le site : un filtre WordPress permet de forcer la désactivation pour l’ensemble des comptes. Attention, le filtre l’emporte sur la préférence individuelle : si vous le posez, vous décidez pour tout le monde.
3. Sans toucher au code : l’extension WP Accessibility propose l’option inverse et gère ça pour vous.

Joe Dolson est un des contributeurs historiques de l’équipe accessibilité de WordPress, et il est d’ailleurs l’un des deux responsables techniques de cette version 7.1. Son extension corrige depuis des années ce que le cœur laisse passer… et elle continue, visiblement.

Une régression, c’est pénible. Une régression documentée, avec ses contournements listés par le projet lui-même, c’est déjà beaucoup mieux que le silence. On l’oublie trop souvent : la transparence sur les défauts vaut mieux qu’une communication lisse.

Qu’est-ce qui n’est finalement pas passé dans la 7.1 ?

Nouveauté appréciable : le guide officiel liste désormais ce qui était prévu et qui a été refusé ou repoussé. C’est rare, et c’est précieux quand on planifie des mises à jour clients.

1. Le bloc Classique reste disponible. Il était question de le masquer dans l’inséreur, la proposition a été annulée après discussions et tests.
2. Le passage à React 19 est reporté au-delà de la 7.1, l’expérimentation continue dans l’extension Gutenberg.
3. La co-édition en temps réel n’est pas activée, malgré des tests approfondis pendant tout le cycle. Le guide a été écrit le 13 août : à cette date, son moteur était encore dans le cœur.
4. Le widget "Aujourd’hui", proposé par Matt Mullenweg lui-même, n’a pas été retenu dans la version finale.

Même le fondateur du projet ne fait pas passer sa proposition en force. C’est plutôt bon signe pour la gouvernance… même si ça alimente exactement ce que je disais en ouverture.

Faut-il mettre à jour tout de suite ?

Pour un site personnel ou une vitrine simple : oui, sans hésiter.

Pour un site en production avec du code maison, des extensions anciennes ou une boutique : attendez une semaine et testez d’abord. Voici les trois points qui méritent votre attention.

1. La bibliothèque jQuery UI passe en 1.14.2. C’est le genre de montée qui casse discrètement un calendrier de réservation ou un sélecteur de date dans une extension mal entretenue.
2. L’iframe de l’éditeur s’applique désormais partout, boîtes méta historiques comprises. Tout script qui sortait du cadre doit être revérifié.
3. La barre d’administration devient persistante d’un écran à l’autre, dans tous les éditeurs. Si vous injectez des éléments dedans, contrôlez leur comportement pendant la navigation.

Bonne nouvelle en revanche du côté de la base de données : la 7.1 porte exactement le même numéro de version de schéma que la 7.0. Aucune migration ne sera jouée pendant la mise à jour, ce qui retire le risque le plus désagréable de l’opération.

Comment tester une version avant sa sortie ?

C’est exactement ce que j’ai fait pour cet article, et sans ça je serais passé à côté de toute l’histoire du moteur de co-édition. Vous installez l’extension officielle sur un site de test (jamais en production, faut-il le préciser), vous choisissez le canal des versions candidates, et vous mettez à jour. Une demi-heure, montre en main.

Pourquoi si peu d’installations actives pour une extension officielle ? Parce qu’on l’installe le temps d’un test, puis on la retire. Ça vous parle ?

Si vous hébergez ou maintenez des sites pour des clients, ce test en amont n’est pas un luxe. C’est ce qui fait la différence entre "on a mis à jour, tout va bien" et un vendredi soir à retrouver pourquoi le formulaire de devis ne part plus. Et si vous préférez déléguer ce travail de veille et de test, c’est précisément ce que je fais en maintenance WordPress.

Questions fréquentes

Quand est sortie WordPress 7.1 ?

WordPress 7.1 "Mary Lou" est sortie le 19 août 2026, soit trois mois après la version 7.0. Le guide officiel des changements techniques a été publié quelques jours avant, le 13 août.

Quels sont les nouveaux blocs de WordPress 7.1 ?

Deux blocs font leur entrée dans le cœur : le bloc Onglets, rangé dans la catégorie Design, et le bloc Liste de lecture en catégorie Média, avec sa visualisation en forme d’onde déclinée en six styles. Le cœur passe de 109 à 115 dossiers de blocs, les quatre autres étant des blocs enfants de ces deux-là. Tous deux ont été stabilisés dans Gutenberg 23.6 après une période expérimentale.

La co-édition en temps réel arrive-t-elle avec WordPress 7.1 ?

Non, et elle a même reculé. Son moteur de synchronisation était présent et chargé dans la troisième version candidate : le paquet sync.min.js (132 275 octets) était déclaré comme dépendance de core-data et exposait la bibliothèque Yjs. Dans la version publiée le 19 août, ce paquet et tout le dossier PHP wp-includes/collaboration ont été supprimés du cœur. La page officielle de la 7.1 les liste parmi ses fichiers supprimés. Aucune version cible n’a été annoncée.

Peut-on travailler à plusieurs sur un contenu en WordPress 7.1 ?

Oui, mais de façon asynchrone. Les notes acceptent maintenant le texte enrichi et les mentions : en tapant le caractère arobase, vous désignez une personne du site, qui reçoit une notification par courriel. Une note peut être accrochée à un passage précis du texte. L’édition simultanée à plusieurs curseurs, elle, n’existe pas.

Faut-il changer de version PHP pour WordPress 7.1 ?

Non. Les exigences ne changent pas par rapport à la 7.0 : le fichier de version de WordPress 7.1 indique toujours PHP 7.4 comme minimum et MySQL 5.5.5. La page officielle des prérequis recommande néanmoins PHP 8.3 ou supérieur, avec MariaDB 10.11+ ou MySQL 8.0+, et rappelle que les versions minimales ont atteint leur fin de vie et peuvent exposer votre site à des failles.

Comment désactiver le défilement infini de la médiathèque ?

Trois options : cocher la case prévue dans Comptes > Profil, section Options personnelles, ce qui ne vaut que pour votre compte ; poser un filtre WordPress qui désactive la fonction pour tout le site, sachant qu’il prend le pas sur les préférences individuelles ; ou installer l’extension WP Accessibility, qui inverse le comportement par défaut.

Ce que je vais surveiller

Un moteur de synchronisation complet, écrit, livré dans une version candidate, chargé dans chaque éditeur, puis retiré quatre jours avant la sortie. Ce code existe, il fonctionne assez bien pour avoir passé tout un cycle de tests, et il dort maintenant quelque part dans le dépôt de Gutenberg.

Ma lecture : il reviendra par l’extension Gutenberg, pour être éprouvé en vrai avant de retenter le cœur. Ce serait la décision raisonnable, et ce serait surtout une bonne nouvelle : ce qui a manqué à cette fonctionnalité, ce n’est pas du code, c’est du terrain.

D’ici là, testez la version candidate sur un site jetable avant de toucher à vos sites en production. Ça prend une demi-heure et ça évite les mauvaises surprises… je le refais avant chaque version majeure, et cette fois-ci, ça m’a permis de voir une fonctionnalité entière disparaître en quatre jours.

Article original sur WPFormation