WordPress 7.1 : styles responsives, pseudo-états et éditeur toujours en iframe

WordPress 7.1 est disponible depuis le 19 août 2026, publié le dernier jour du WordCamp US de Phoenix. La version prolonge le socle technique posé par 7.0 et se concentre sur l’expérience de conception : styles responsives natifs, pseudo-états dans theme.json, et une API publique pour les icônes SVG de l’éditeur. Un changement plus discret mérite l’attention des développeurs de thèmes : l’éditeur de contenu est maintenant systématiquement rendu en iframe.

#Les styles responsives entrent dans l’éditeur

Jusqu’ici, adapter un bloc au mobile passait par des requêtes média écrites à la main dans une feuille de style de thème. WordPress 7.1 déplace ce réglage dans l’éditeur : des styles peuvent être définis pour les points de rupture tablette et mobile, aussi bien dans les styles globaux par type de bloc que sur une instance particulière. Les thèmes déclarent leurs points de rupture via settings.viewport dans theme.json, avec pour valeurs par défaut 480 px pour le mobile et 782 px pour la tablette.

{
  "version": 3,
  "settings": {
    "viewport": {
      "mobile": { "width": "480px" },
      "tablet": { "width": "782px" }
    }
  }
}

Le seuil de 782 px n’est pas choisi au hasard : c’est la limite que l’administration WordPress utilise déjà pour basculer en affichage mobile. Aligner les points de rupture de contenu sur cette valeur évite les décalages entre l’aperçu de l’éditeur et le rendu réel.

#Pseudo-états et API d’icônes SVG

La version 7.1 introduit la prise en charge des états :hover, :focus, :focus-visible et :active dans theme.json et dans l’éditeur. La fonctionnalité reste d’abord limitée aux blocs Bouton et Lien de navigation, les deux cas où l’état survolé était jusqu’ici impossible à régler sans CSS additionnel.

Autre chantier arrivé à maturité : le jeu d’icônes SVG livré avec l’éditeur depuis WordPress 7.0 devient une véritable API publique. Une extension ou un thème peut désormais enregistrer sa propre collection et réutiliser les icônes côté serveur comme dans le bloc Icône.

<?php
add_action( 'init', function () {
    wp_register_icon_collection( 'mastudio', array(
        'label' => 'Mail Studio',
    ) );

    wp_register_icon( 'mastudio/rss', array(
        'label' => 'Flux RSS',
        'path'  => 'M4 11a9 9 0 0 1 9 9M4 4a16 16 0 0 1 16 16',
    ) );
} );

// Rendu côté serveur, par exemple dans un template de bloc :
echo wp_get_icon( 'mastudio/rss', array( 'size' => 24 ) );

WordPress 7.1 ajoute au passage les fonctions d’assistance wp_get_tooltip() et wp_get_toggletip(), ainsi que deux nouveaux supports de blocs, background.gradient et dimensions.minWidth. React, lui, reste en version 18.3 : le passage à React 19 est repoussé à une version ultérieure.

#L’éditeur toujours en iframe : le vrai point de vigilance

Depuis plusieurs versions, l’éditeur de blocs migrait progressivement vers un rendu en iframe pour isoler les styles du contenu de ceux de l’administration. WordPress 7.1 franchit la dernière étape : l’éditeur de contenu est désormais toujours encapsulé en iframe, quel que soit le type de thème, y compris les thèmes classiques qui échappaient encore à cette bascule.

L’éditeur de contenu de WordPress 7.1 est encapsulé en iframe quel que soit le type de thème, thèmes classiques compris.

La conséquence est concrète pour qui maintient un thème classique : les styles d’éditeur injectés via une simple feuille d’administration, sans passer par le mécanisme d’enregistrement prévu, ne franchissent plus la frontière de l’iframe. Ils doivent être déclarés avec add_editor_style() ou enregistrés comme ressources d’éditeur pour réapparaître dans l’aperçu.

#Ce qui change, en un tableau

#Ce qu’il faut retenir

WordPress 7.1 déplace vers l’éditeur des réglages qui relevaient jusqu’ici du CSS de thème : styles responsives, pseudo-états, icônes. Pour les auteurs, c’est du contrôle gagné sans code. Pour les développeurs, le vrai poste de contrôle avant mise à jour reste l’iframe systématique de l’éditeur, qui peut faire disparaître des styles d’aperçu sur les thèmes classiques mal outillés. Une version à tester d’abord sur un environnement de préproduction, thème par thème.

#Pour aller plus loin

Le détail des nouveautés développeurs, sur la source primaire : What’s new for developers (August 2026) — WordPress Developer Blog. Voir aussi le guide pilier Auto-hébergement WordPress.

#À lire aussi sur Mail Studio

Hardening WordPress : le socle sécurité minimal
CloudPanel : l’auto-hébergement WordPress sans panneau lourd