WordPress 7.1 « Mary Lou » est disponible : toutes les nouveautés

WordPress 7.1 est disponible en version stable depuis le 19 août 2026. Baptisée « Mary Lou » en hommage à la pianiste, compositrice et arrangeuse de jazz Mary Lou Williams, cette version rassemble plus de 1 500 améliorations et corrections réalisées avec la participation de plus de 800 contributeurs, dont plus de 170 nouveaux venus.

Cette mise à jour apporte les styles responsive dans l’éditeur, une nouvelle interface de recadrage, des Notes enrichies avec mentions, le traitement de certaines images directement dans le navigateur, les blocs Playlist et Tabs ainsi qu’une barre d’administration présente dans tous les éditeurs. Les développeurs disposent aussi d’une API publique pour enregistrer des icônes SVG, d’une Abilities API enrichie et de nouvelles fondations pour harmoniser les interfaces d’administration.

Sommaire

• WordPress 7.1 est disponible
• Les derniers ajustements des RC3 et RC4
• Installer WordPress 7.1
• Le calendrier de publication
• Les fonctionnalités de WordPress 7.1
  • Collaboration et Notes
  • Médias
  • Styles et personnalisation
  • Blocs et édition
  • APIs et outils pour les développeurs
  • Administration
  • IA
  • Performance
• Les fonctionnalités absentes de la version finale

WordPress 7.1 est disponible

Le nom « Mary Lou » fait référence à Mary Lou Williams, dont le parcours traverse le swing, le bebop et le jazz sacré. WordPress rapproche cette capacité à se réinventer et à collaborer de l’orientation donnée à la version 7.1.

La publication finale confirme les principales fonctions testées pendant l’été. Les blocs peuvent recevoir des styles différents selon la taille d’écran et, pour certains d’entre eux, selon leurs états hover, focus ou active. La nouvelle modale média réunit recadrage libre, ratios prédéfinis, rotation, retournement et modification des métadonnées. Les Notes peuvent viser une sélection de texte, utiliser du texte enrichi et notifier une personne mentionnée avec @.

Le traitement des médias côté client réduit le travail demandé au serveur pour la compression, le redimensionnement et la génération des miniatures. WordPress ajoute aussi une meilleure prise en charge d’AVIF, HEIC et des cartes de gain HDR. Les blocs Playlist et Tabs sont livrés en version stable, tandis que le passage systématique de l’éditeur de publication dans une iframe rend son affichage plus prévisible entre les thèmes.

Le Field Guide de WordPress 7.1 rassemble les Dev Notes du cycle et complète la présentation des changements destinés aux développeurs.

Les derniers ajustements des RC3 et RC4

Le cycle ne s’est pas arrêté à la RC1. Une RC2 a été publiée le 6 août avec les correctifs de sécurité de WordPress 7.0.3. La RC3 du 12 août a ensuite intégré le correctif de sécurité distribué dans WordPress 7.0.4. Elle totalisait plus de 90 mises à jour et corrections depuis la RC1, dont 37 dans l’éditeur et 57 dans le Core. Cette étape a également marqué le gel définitif des chaînes à traduire.

La RC4 publiée le 17 août a ajouté plus de 26 ajustements depuis la RC3, dont 8 dans l’éditeur et 18 dans le Core. Elle a été immédiatement suivie de la répétition générale et a servi de dernière étape de stabilisation avant la sortie du 19 août.

Au total, l’annonce finale recense plus de 1 500 améliorations et corrections. Le Field Guide détaille plus de 310 tickets Core, dont plus de 180 corrections de bugs, auxquels s’ajoutent plus de 630 corrections issues de Gutenberg.

Installer WordPress 7.1

WordPress 7.1 est une version stable. Elle peut être installée depuis Tableau de bord > Mises à jour ou téléchargée depuis WordPress.org. Une sauvegarde complète des fichiers et de la base de données reste recommandée avant la migration.

Les sites qui dépendent de blocs personnalisés ou d’extensions modifiant l’éditeur doivent vérifier leur compatibilité avec l’iframe désormais systématique. Les extensions qui interviennent sur le traitement des images, chargent des ressources externes dans l’éditeur ou utilisent des composants WordPress personnalisés méritent également un test sur un environnement de staging.

Attention aux anciennes versions de WP Rocket

La sortie de WordPress 7.1 a révélé une incompatibilité avec certaines versions de WP Rocket. Dans certaines configurations utilisant PHP 8 ou une version plus récente, elle peut provoquer une erreur fatale lors du chargement de WordPress et rendre le site ou son administration inaccessible. Le problème vient d’une valeur numérique transmise à substr() dans le code associé à l’intégration Cloudflare de WP Rocket. Le ticket technique a toutefois reproduit l’erreur sans que l’extension officielle Cloudflare soit installée : le risque ne doit donc pas être limité aux seuls sites qui l’utilisent.

WP Rocket a publié le correctif dans la version 3.23.2.2 le 20 août 2026. Les utilisateurs de l’extension ont intérêt à installer WP Rocket 3.23.2.2 ou une version plus récente avant de passer à WordPress 7.1. Si l’erreur empêche déjà d’accéder à l’administration, l’éditeur explique comment désactiver temporairement l’extension puis forcer sa mise à jour dans sa procédure de récupération officielle. Le journal des versions de WP Rocket et le ticket technique public confirment le correctif.

Pour les développeurs de thèmes et d’extensions, le passage du champ « Tested up to » à 7.1 doit intervenir après ces vérifications, pas uniquement après une installation réussie.

Calendrier de publication de WordPress 7.1

Sources : calendrier du cycle et déroulement effectif de la publication.

Fonctionnalités de WordPress 7.1

La version finale confirme l’orientation annoncée dans la feuille de route publiée par l’équipe Core le 19 juin 2026 : collaboration asynchrone, personnalisation dans l’éditeur, médias, APIs et poursuite des fondations liées à l’IA. Certaines fonctions explorées pendant le cycle ont toutefois été reportées.

Collaboration et Notes

Retirée de WordPress 7.0 en raison de problèmes techniques, la collaboration en temps réel n’est finalement pas incluse dans WordPress 7.1. Le travail se poursuit, mais deux personnes ne peuvent pas encore modifier simultanément un même contenu avec le Core seul.

Les avancées livrées concernent la collaboration asynchrone. Les Notes acceptent le gras, l’italique, le code, les liens et les mentions @. Plusieurs conversations peuvent être ouvertes sur un même bloc, une note peut viser une sélection de texte et les commentaires longs peuvent être repliés. Une mention peut déclencher une notification afin d’attirer l’attention de la personne concernée. Les réactions par émoji évoquées dans la feuille de route ne sont pas documentées parmi les fonctions de la version finale.

Le traitement des médias côté client intégré au Core

Initialement prévu pour WordPress 7.0 puis retiré pendant son cycle de développement, le traitement des médias côté client fait partie de WordPress 7.1. La fonctionnalité est activée par défaut dans les navigateurs compatibles.

WordPress s’appuie sur wasm-vips, une version WebAssembly de la bibliothèque libvips, pour compresser, redimensionner, recadrer, convertir et orienter les images directement dans un Web Worker. Les miniatures sont également générées dans le navigateur, puis envoyées individuellement au serveur avec l’image traitée. Cette architecture réduit la consommation de mémoire et de processeur côté serveur et évite une partie des échecs liés aux limites de mémoire de PHP.

Le périmètre couvre plusieurs formats modernes. Les images HEIC et HEIF peuvent être converties en JPEG avant leur envoi, tout en conservant l’original comme fichier associé. Les images AVIF peuvent être acceptées même si le serveur ne sait pas les traiter, tandis que les cartes de gain des images Ultra HDR sont préservées dans les différentes tailles générées.

Les GIF animés opaques peuvent être convertis en une vidéo MP4 ou WebM accompagnée d’une image d’affiche. Le média reste enregistré comme une seule pièce jointe GIF dans la médiathèque, mais l’éditeur peut le transformer en bloc Vidéo avec lecture automatique, boucle et son coupé. Les GIF transparents et les navigateurs dépourvus des APIs nécessaires conservent le fichier GIF d’origine.

Les téléversements deviennent aussi plus résistants aux coupures. Chaque taille est envoyée séparément, les requêtes qui échouent sont relancées automatiquement et un envoi interrompu hors ligne reprend après le retour de la connexion.

Le traitement complet repose actuellement sur Document-Isolation-Policy et fonctionne par défaut avec Chrome et Edge 137 ou une version plus récente, ainsi qu’avec Chrome 146 sur Android. Firefox et Safari utilisent automatiquement le traitement classique côté serveur. Safari peut néanmoins décoder les images HEIC dans le navigateur. Le retour au traitement serveur est également automatique si l’appareil manque de mémoire ou de puissance, si la connexion est trop lente ou si la politique de sécurité du site bloque le Web Worker.

Pour les développeurs, les filtres habituels de qualité et de conversion, dont wp_editor_set_quality, jpeg_quality et image_editor_output_format, restent pris en compte. Le filtre wp_generate_attachment_metadata continue aussi d’être exécuté, d’abord avec le contexte create, puis avec update une fois les différentes tailles envoyées. En revanche, les hooks strictement liés au traitement serveur, comme wp_image_editors, image_memory_limit et image_make_intermediate_size, ne sont pas déclenchés lorsque le navigateur réalise le travail. La fonctionnalité peut être désactivée avec le filtre wp_client_side_media_processing_enabled.

Les extensions qui chargent des ressources externes dans l’éditeur doivent enfin vérifier leur compatibilité avec l’isolation du document. Une politique CSP personnalisée doit notamment autoriser blob: dans la directive worker-src, faute de quoi WordPress revient au traitement côté serveur.

Dev Note sur le traitement des médias côté client dans WordPress 7.1.

Une modale d’édition et le défilement infini

Une nouvelle modale regroupe le recadrage libre, les ratios prédéfinis, la rotation, le retournement et l’édition des métadonnées. Elle remplace l’outil de recadrage intégré au bloc tout en conservant le bouton « Recadrer » comme point d’entrée.

La vue en grille de la médiathèque et la modale de sélection activent désormais le défilement infini par défaut. De nouveaux médias se chargent donc automatiquement pendant le défilement, sans passer par le bouton « Charger davantage ». Chaque utilisateur disposant de la capacité upload_files peut retrouver l’ancien comportement grâce à une option de son profil.

Ce retour marque un changement de cap. Le défilement infini était utilisé par défaut dans la médiathèque avant que WordPress 5.8 le remplace, dans le comportement standard, par un bouton « Charger davantage ». La fonction n’avait pas entièrement disparu : un thème ou une extension pouvait toujours la réactiver avec le filtre media_library_infinite_scrolling, mais WordPress ne proposait aucune option correspondante dans son interface. Cette décision répondait à des difficultés documentées par l’équipe Accessibilité. Les utilisateurs naviguant au clavier pouvaient avoir du mal à atteindre les éléments situés après une grille qui continuait à se remplir, tandis que les lecteurs d’écran ne recevaient pas d’informations suffisamment claires sur le chargement de nouveaux médias. À ces obstacles s’ajoutaient des problèmes possibles de mémoire, de performance et d’utilisation sur les grandes bibliothèques.

Le bouton « Charger davantage » a toutefois créé une autre forme de friction pour les personnes qui manipulent beaucoup de médias. Il impose une action répétée et ralentit la consultation des bibliothèques volumineuses. Un besoin de retrouver l’ancien fonctionnement existe bien : l’extension Media Library Enable Infinite Scrolling, publiée après WordPress 5.8, se présentait initialement comme une réponse à court terme au changement. Elle a pourtant perduré jusqu’au cycle de WordPress 7.1, compte plus de 8 000 installations actives et avait déjà envisagé un réglage propre à chaque utilisateur. Ce chiffre reste modeste à l’échelle de WordPress et ne permet pas de conclure à une demande majoritaire. La longévité de l’extension montre néanmoins qu’une partie des utilisateurs cherchait durablement à contourner le nouveau comportement.

WordPress 7.1 tente donc de concilier ces deux besoins en réactivant le défilement infini par défaut tout en permettant à chaque utilisateur de le désactiver. Ce compromis reste néanmoins discutable du point de vue de l’accessibilité. La version ne remplace pas le mécanisme historique par une nouvelle implémentation qui corrigerait les difficultés signalées : elle inverse surtout son réglage par défaut. Les personnes concernées devront connaître l’existence de l’option, comprendre que le défilement infini est à l’origine de leurs difficultés, puis se rendre dans leur profil pour retrouver le bouton « Charger davantage ». Le réglage individuel atténue donc le problème, mais ne supprime pas la friction créée par cette logique d’opt-out.

Pour les développeurs, le filtre media_library_infinite_scrolling conserve la même signature, mais sa valeur par défaut passe de false à true. Un filtre ajouté par une extension ou un thème reste prioritaire sur le choix individuel, lui-même prioritaire sur le comportement par défaut. Les sites qui souhaitent conserver le bouton pour tous les comptes peuvent donc toujours renvoyer false avec ce filtre.

Dev Note sur le défilement infini de la médiathèque.

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

WordPress 7.1 introduit deux demandes anciennes de l’édition full-site : la personnalisation responsive et les styles d’état. L’apparence d’un bloc peut être adaptée à la taille de l’écran ou à un état d’interaction comme hover, focus ou active, directement dans les styles globaux ou sur une instance précise, sans passer systématiquement par du CSS personnalisé.

Les thèmes peuvent déclarer leurs propres points de rupture dans theme.json, ce qui leur donne davantage de contrôle sur les vues mobile, tablette et desktop. Un appel à tests publié le 3 juillet 2026 présente cette évolution comme une amélioration progressive de l’éditeur plutôt que comme un nouveau système indépendant.

La feuille de route prévoyait aussi de mieux indiquer l’origine d’un style appliqué à un bloc, qu’il provienne du thème, des styles globaux, d’un bloc parent ou d’une personnalisation locale. À cette heure, cette fonction n’apparaît toutefois ni dans le Field Guide ni dans l’annonce finale. Une vérification complémentaire dans la version stable reste nécessaire avant de la considérer comme livrée.

WordPress 7.1 ajoute par ailleurs un réglage natif de largeur minimale. Lorsqu’un bloc active le support dimensions.minWidth, une option « Largeur minimale » devient disponible dans le panneau Dimensions et produit la propriété CSS min-width. Les thèmes peuvent l’activer ou lui attribuer une valeur globale ou propre à un bloc dans theme.json, avec la possibilité d’utiliser leurs préréglages de dimensions.

Ce support reste facultatif et uniquement additif : les blocs doivent l’activer pour proposer le réglage, et les thèmes qui ne l’utilisent pas conservent leur comportement actuel. La Dev Note consacrée à la largeur minimale précise également que l’option apparaît par défaut dans les Styles globaux pour les blocs compatibles, mais peut rester masquée dans l’inspecteur jusqu’à son activation depuis le menu du panneau.

Une première prise en charge des ombres de texte

WordPress 7.1 intègre une première étape du support de la propriété CSS text-shadow dans les styles globaux. Les thèmes peuvent désormais déclarer une valeur textShadow dans theme.json pour l’ensemble de la typographie, pour un type de bloc précis ou pour un élément comme un lien, y compris dans un état tel que :hover.

La valeur est transmise directement à la propriété CSS text-shadow. Elle peut donc contenir toute valeur valide, y compris plusieurs ombres séparées par des virgules. Une valeur définie pour un bloc remplace la valeur globale selon la cascade habituelle des styles WordPress.

Cette intégration reste limitée à la configuration dans theme.json. WordPress 7.1 ne fournit pas encore de contrôle dans l’inspecteur de bloc, d’interface dédiée dans les Styles globaux, de préréglages d’ombres ni de support supports.typography.textShadow pour les blocs. Ces éléments sont prévus pour une version ultérieure.

Le changement est uniquement additif : les thèmes qui ne déclarent pas textShadow conservent leur comportement actuel.

Dev Note sur les ombres de texte dans les Styles globaux.

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. Playlist et Tabs sont confirmés dans la version finale. À cette heure, le bloc Table des matières ne figure pas dans l’annonce finale et nécessite une vérification complémentaire avant d’être considéré comme livré. D’autres améliorations concernent les blocs existants, comme le lightbox de galerie, un réglage permettant de marquer une image comme décorative pour les lecteurs d’écran ou encore de meilleures conversions depuis les shortcodes.

La version finale livre 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 Image propose une option pour déclarer une image décorative aux technologies d’assistance.

Le nouveau support background.gradient permet de superposer un dégradé et une image d’arrière-plan sur un même bloc. Le dégradé est enregistré séparément de l’ancien color.gradient et rendu avec la propriété CSS background-image, ce qui évite d’écraser l’image déjà définie. Dans WordPress 7.1, les blocs Groupe, Accordéon, Citation en exergue, Contenu de la publication et Citation activent ce support. Les blocs et les thèmes qui utilisent l’ancien système conservent leur comportement actuel. La Dev Note sur les dégradés d’arrière-plan détaille son activation dans block.json et theme.json.

Le bloc HTML personnalisé peut désormais mêler du balisage statique et des blocs WordPress éditables. Dans l’éditeur, le balisage HTML statique n’est pas modifiable, tandis que les blocs imbriqués peuvent être édités sur place. Ces derniers sont verrouillés : ils ne peuvent pas être déplacés ou supprimés, et il n’est pas possible de leur ajouter des blocs voisins. Le code complet reste accessible dans la modale « Modifier le HTML » et sa sérialisation demeure inchangée afin de ne pas casser les contenus existants.

Les extensions peuvent aussi enregistrer des variations de core/html avec un champ innerContent. Celui-ci décrit une enveloppe HTML fixe et indique, avec des valeurs null, les emplacements réservés aux blocs éditables définis dans innerBlocks. Une variation peut ainsi proposer dans l’outil d’insertion un composant structuré avec quelques zones de contenu modifiables, sans nécessiter la création ni la compilation d’un bloc personnalisé.

Dev Note sur les blocs éditables dans le bloc HTML personnalisé.

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 et outils pour les développeurs

WordPress 7.1 poursuit également plusieurs chantiers d’infrastructure. L’Abilities API expose 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 envisageait d’ajouter trois capacités de lecture dans le Core : réglages, contenus et utilisateurs. À cette heure, ces trois nouvelles abilities ne figurent pas dans la documentation finale de WordPress 7.1. Leur présence dans la version stable doit donc être vérifiée avant de les considérer comme livrées. Les Block Bindings sont par ailleurs étendus aux éléments de liste et aux blocs imbriqués.

La version ajoute aussi quatre filtres au cycle d’exécution de l’Abilities API. Les extensions peuvent interrompre une capacité avant son exécution avec wp_pre_execute_ability, normaliser ou enrichir ses données d’entrée avec wp_ability_normalize_input, appliquer des règles d’autorisation supplémentaires avec wp_ability_permission_result, puis transformer son résultat ou prévoir une solution de repli avec wp_ability_execute_result. Ces points d’extension ouvrent notamment la voie à la mise en cache, à la limitation du nombre de requêtes, aux modes de maintenance et au filtrage des réponses. Les valeurs modifiées restent contrôlées par les schémas d’entrée et de sortie déclarés par la capacité. Ce changement est additif : les capacités existantes et les actions wp_before_execute_ability et wp_after_execute_ability conservent leur comportement. La Dev Note sur les nouveaux filtres de l’Abilities API détaille leur ordre d’exécution et leurs précautions d’utilisation.

Deux filtres supplémentaires, wp_ability_validate_input et wp_ability_validate_output, permettent d’ajouter des règles de validation impossibles à exprimer avec le JSON Schema pris en charge par WordPress. Les mots-clés validate_callback et sanitize_callback utilisés dans les schémas REST ne sont pas exécutés par l’Abilities API : les extensions qui ont besoin d’une validation personnalisée doivent donc passer par ces nouveaux filtres. L’action wp_ability_invoked se déclenche par ailleurs au début de chaque appel, y compris lorsque les données sont invalides, que les permissions échouent ou que l’exécution est interrompue. Elle facilite l’audit et la télémétrie, mais reçoit les données brutes : celles-ci ne doivent pas être enregistrées sans filtrage, car elles peuvent contenir des informations sensibles.

Les abilities fournies par le Core gagnent aussi des réponses plus cohérentes. core/get-user-info expose cinq informations de profil supplémentaires et devient accessible par l’API REST pour les clients authentifiés. Cette ability et core/get-environment-info acceptent désormais un paramètre fields pour limiter les propriétés retournées. Lors d’un appel REST en GET ou DELETE, WordPress convertit en outre les valeurs reçues vers les types déclarés dans input_schema : un entier, un booléen ou une liste n’arrive plus systématiquement sous la forme d’une chaîne de caractères. La Dev Note consacrée aux améliorations de l’Abilities API détaille ces changements.

WordPress 7.1 ajoute enfin wp_prepare_json_schema_for_client(), une fonction qui transforme les schémas internes de WordPress en représentations JSON Schema Draft 4 adaptées aux clients externes. Elle normalise notamment les propriétés obligatoires, retire les callbacks PHP et les autres mots-clés réservés au serveur, puis corrige la représentation des objets vides. Cette préparation est appliquée automatiquement aux schémas de l’Abilities API renvoyés par REST et aux déclarations de fonctions produites pour l’AI Client. Les extensions doivent l’appeler elles-mêmes lorsqu’elles exposent un schéma WordPress par un endpoint REST personnalisé, une configuration JavaScript, un outil MCP ou une autre intégration externe, tout en conservant le schéma d’origine pour la validation côté serveur. La Dev Note sur la compatibilité des JSON Schema présente les transformations et les deux profils disponibles, draft-04 et rest-api.

WordPress 7.1 permet également aux extensions de configurer depuis PHP quatre écrans de l’éditeur de site : Pages, Modèles, Éléments de modèles et Compositions. Ces nouveaux filtres peuvent modifier les champs affichés par défaut, l’ordre de tri, les modes de présentation disponibles, les vues proposées dans la barre latérale et les champs du formulaire de modification rapide. Ils s’appuient sur les composants DataViews et DataForm, avec l’objectif d’étendre ensuite ce mécanisme à d’autres types de contenus. La Dev Note sur le filtrage des écrans de l’éditeur de site présente les quatre filtres et leur API.

La transition de l’éditeur de publication vers une iframe franchit sa dernière étape. Dans WordPress 7.1, cet éditeur utilise toujours une iframe, quel que soit le type de thème et indépendamment de la version de la Block API employée par les blocs enregistrés ou présents dans le contenu.

WordPress 7.0 conservait encore un fonctionnement conditionnel. L’iframe était utilisée lorsque tous les blocs insérés dans la publication reposaient sur la version 3 ou une version plus récente de la Block API, puis retirée dès qu’un bloc plus ancien était présent. L’éditeur pouvait donc changer de mode selon le contenu. L’extension Gutenberg impose déjà l’iframe depuis sa version 22.6 afin de faire remonter les problèmes de compatibilité avant leur arrivée dans le Core.

La plupart des blocs doivent continuer à fonctionner sans modification. Les développeurs doivent néanmoins tester leurs blocs personnalisés et les extensions qui modifient des blocs. Le document et la fenêtre de l’iframe sont distincts de ceux de la page d’administration : un script qui utilise directement les objets globaux document ou window risque donc de cibler le mauvais contexte. WordPress recommande de récupérer le document depuis un élément de la zone d’édition avec ownerDocument, puis sa fenêtre avec defaultView, et d’utiliser useRefEffect pour ajouter et retirer proprement les écouteurs d’événements.

Dev Note sur le passage systématique de l’éditeur de publication dans une iframe.

jQuery UI passe à la version 1.14.2

WordPress 7.1 met à jour jQuery UI de la version 1.13.3 vers la version 1.14.2. Cette branche ne prend plus en charge Internet Explorer ni l’ancien Microsoft Edge, conformément à la politique de compatibilité des navigateurs de WordPress.

Le Core active toutefois jQuery.uiBackCompat afin de préserver le fonctionnement du code écrit pour l’API jQuery UI 1.11. Cette couche de compatibilité ne couvre pas tout : $.fn._form, $.ui.ie, $.ui.safeActiveElement et $.ui.safeBlur ont été supprimés. WordPress ne les utilise pas directement, mais les développeurs de thèmes et d’extensions doivent vérifier qu’ils n’en dépendent pas et adapter leur code si nécessaire.

Dev Note sur le passage à jQuery UI 1.14.2 dans WordPress 7.1.

Une API publique pour enregistrer et afficher des icônes SVG

WordPress 7.0 avait introduit un jeu d’icônes SVG utilisé par l’éditeur et le bloc Icône. WordPress 7.1 transforme ce système en API publique. Les thèmes et extensions peuvent créer une collection avec wp_register_icon_collection(), puis y ajouter des icônes avec wp_register_icon(). Le nom complet suit la forme collection/icone, ce qui évite les conflits entre le Core et les différentes extensions. Les fonctions wp_unregister_icon() et wp_unregister_icon_collection() permettent de retirer une icône ou toute une collection.

Le SVG peut être fourni directement dans content ou chargé depuis un fichier avec file_path. WordPress le nettoie avec une liste volontairement limitée aux éléments <svg>, <path> et <polygon> ainsi qu’à quelques attributs autorisés. Cette restriction exclut pour le moment les scripts, les styles en ligne et les icônes basées sur stroke. Le contenu d’un fichier n’est lu qu’au premier affichage ou à la première requête REST, et non au moment de l’enregistrement.

La fonction wp_get_icon() renvoie le balisage d’une icône enregistrée avec une taille, une classe CSS et, si nécessaire, un libellé accessible. Sans libellé, l’icône est considérée comme décorative et masquée aux lecteurs d’écran. Des routes REST en lecture seule exposent les collections et les icônes aux utilisateurs autorisés à modifier des contenus.

Dans le bloc Icône, le sélecteur classe les icônes par collection et permet de chercher dans une collection ou dans l’ensemble du catalogue. Le bloc gagne aussi des commandes de retournement et de rotation, et utilise désormais core/info comme icône initiale.

Dev Note sur l’enregistrement et l’affichage des icônes SVG.

Des composants d’interface plus grands et plusieurs retraits

Les contrôles de formulaire de @wordpress/components passent définitivement à une hauteur de 40 pixels. La propriété __next40pxDefaultSize, proposée depuis WordPress 6.7 pour anticiper cette évolution, n’a plus aucun effet et doit être retirée. Il n’est plus possible de revenir à l’ancienne hauteur de 36 pixels avec la valeur false. Cette évolution ne concerne pas encore le composant Button, qui conserve son mécanisme d’activation.

La migration des styles d’Emotion vers des modules SCSS se poursuit également. Pour les développeurs qui personnalisent les composants, la propriété css de View reste acceptée pour la compatibilité des types, mais elle ne produit plus de style. Il faut utiliser style ou className. Les fragments Emotion dont l’ordre détermine la cascade doivent aussi être réunis dans un même appel à css() avant leur passage à cx().

Deux éléments dépréciés depuis WordPress 6.8 disparaissent enfin. Le composant Navigation et ses sous-composants sont retirés au profit de Navigator, tandis que l’utilitaire __experimentalApplyValueToSides est supprimé sans modifier le composant BoxControl.

Dev Note sur les composants de l’éditeur dans WordPress 7.1.

Une administration plus cohérente

Côté administration, WordPress 7.1 rend la navigation plus cohérente entre les écrans classiques et les éditeurs. La barre d’administration reste 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 sert plus de bouton de retour : un chevron remplit désormais cette fonction. Le logo WordPress ouvre la page À propos, tandis que l’icône du site donne accès au menu du site. Son titre reste é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.

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. Le widget « On This Day » envisagé dans la feuille de route n’a finalement pas été retenu pour cette version.

La Dev Note publiée le 31 juillet confirme aussi l’intégration des premières fondations d’un système de design commun pour l’administration. Une nouvelle feuille de style wp-theme fournit des design tokens sous forme de variables CSS, tandis qu’un composant React ThemeProvider permet d’adapter notamment les couleurs et l’arrondi des composants. Les extensions pourront s’appuyer sur cette base pour mieux s’intégrer à l’interface de WordPress.

Pour les utilisateurs, le changement doit rester discret et ne constitue pas une refonte de l’administration. L’effet le plus visible dans WordPress 7.1 est l’application du jeu de couleurs choisi dans le profil à l’éditeur de site. Ce socle pourra faciliter plus tard une personnalisation plus large ou un véritable mode sombre, mais ces possibilités ne sont pas encore proposées dans cette version.

IA : des fondations techniques, sans assistant intégré

WordPress 7.1 n’ajoute pas d’assistant génératif visible dans l’administration. La version enrichit surtout l’Abilities API, qui permet aux extensions de décrire des actions disponibles, de filtrer leur découverte, de valider leurs données et de contrôler leur exécution. Ces mécanismes peuvent servir à des automatisations classiques comme à des outils d’IA.

Le cycle a également exploré le streaming, les embeddings, de nouvelles méthodes d’authentification pour les connecteurs et le projet Guidelines. La proposition Guidelines devait fournir un espace structuré pour les règles éditoriales et les connaissances du site. Elle n’a pas été intégrée dans son ensemble à WordPress 7.1. Ces fonctions continuent donc d’évoluer en dehors du périmètre stable de cette version.

Performance

Le traitement des médias côté client constitue le changement le plus visible en matière de performance. La compression, le redimensionnement et la génération des miniatures peuvent s’exécuter dans le navigateur avec une version WebAssembly de libvips, ce qui réduit la charge du serveur et certains risques de dépassement de mémoire.

La conversion facultative des GIF en vidéo peut produire des fichiers plus légers, tandis que les téléversements profitent d’indicateurs de progression et de nouvelles tentatives automatiques. Les réglages du chargement spéculatif peuvent désormais être définis avec des variables d’environnement ou des constantes, sans créer d’extension dédiée.

Source : Roadmap to 7.1.

Ce qui n’est pas dans WordPress 7.1

Parmi les évolutions initialement envisagées, React 19 et les adresses e-mail Unicode ont été retirés du cycle. Leur développement se poursuit en dehors du Core afin de laisser davantage de temps aux tests et au travail de compatibilité.

React 19 reporté au-delà de WordPress 7.1

React 19 ne fait pas partie de WordPress 7.1, qui conserve React 18.3. Après avoir brièvement activé la nouvelle version dans Gutenberg, l’équipe a découvert des incompatibilités entre les deux runtimes et dans la manière dont certaines extensions utilisent React. Le changement avait donc été annulé dès Gutenberg 23.3.2.

L’un des principaux problèmes vient des extensions qui embarquent directement react/jsx-runtime au lieu d’utiliser le script react-jsx-runtime fourni par WordPress. Leur code mélange alors des structures créées par React 18 avec le runtime React 19. D’autres extensions s’appuient encore sur d’anciennes fonctions supprimées dans React 19, comme les références sous forme de chaînes, les defaultProps des composants fonctionnels ou les anciennes APIs de contexte.

Depuis Gutenberg 23.4, React 19 reste accessible sous la forme d’une expérience à activer dans Réglages, puis Gutenberg. Ce mode est destiné aux tests de compatibilité des blocs, des extensions de l’éditeur et des écrans d’administration personnalisés. L’équipe doit encore éprouver et affiner sa couche de compatibilité avant d’envisager l’arrivée de React 19 dans une future version du Core. Plugin Check devrait également apprendre à détecter automatiquement certains de ces problèmes.

Les développeurs peuvent donc préparer leurs extensions dès maintenant, mais sans considérer React 19 comme une dépendance de WordPress 7.1.

Annonce du report de React 19 au-delà de WordPress 7.1.

Les adresses e-mail Unicode également retirées

La prise en charge des adresses e-mail Unicode ne fait finalement pas partie de WordPress 7.1. Le travail engagé devait notamment permettre d’utiliser des adresses contenant des caractères non ASCII, comme grå@grå.org, sur les sites dont la base de données utilise l’encodage utf8mb4.

La fonctionnalité avait été intégrée au Core pendant le développement, avec des adaptations de is_email() et sanitize_email() ainsi qu’une nouvelle classe WP_Email_Address. Elle a été retirée le 22 juillet dans la révision 62829 en raison des questions de compatibilité, de sécurité et de traitement des données qu’elle soulève.

Le projet doit désormais se poursuivre dans une extension communautaire afin de bénéficier de tests plus larges avant une éventuelle nouvelle proposition pour le Core.

Source.