WordPress 7.1 : styles responsives, pseudo-états et API SVG Icon publique

Ce que les styles responsifs changent pour les thèmes

WordPress 7.1 introduit la possibilité de définir des styles par viewport directement dans theme.json. Les développeurs peuvent désormais déclarer des variations pour mobile et tablette sous les clés @mobile et @tablet, sans toucher au CSS personnalisé.

"styles": {
"blocks": {
"core/group": {
"spacing": {
"padding": { "top": "3rem" }
},
"@mobile": {
"spacing": {
"padding": { "top": "1rem" }
}
}
}
}
}

Le style par défaut du bloc reste celui du desktop et s'applique à tous les viewports tant qu'il n'est pas surchargé. Il n'existe pas de clé @desktop : c'est le comportement de base.

Les breakpoints eux-mêmes deviennent configurables via une nouvelle propriété settings.viewport au niveau racine de theme.json. Par défaut, mobile est fixé à 480px et tablette à 782px. Les valeurs acceptées sont des longueurs non négatives en px, em ou rem. Les fonctions CSS, pourcentages et valeurs sans unité sont ignorés. Si la valeur tablette est inférieure ou égale à celle du mobile, seul le mobile est pris en compte.

Les blocs qui s'appuient sur les block supports standards (typographie, couleur, arrière-plan, bordure, dimensions, espacement, layout) héritent automatiquement du support responsive. Les blocs avec des contrôles de style personnalisés doivent l'implémenter eux-mêmes.

Un filtre permet de désactiver l'édition responsive côté utilisateur :

add_filter( 'block_editor_settings_all', 'example_disable_responsive_editing' );
function example_disable_responsive_editing( $settings ) {
$settings['responsiveEditingEnabled'] = false;
return $settings;
}

À noter : l'ajout du support responsive modifie la façon dont Core génère le CSS des blocs. Les sélecteurs d'utilitaires de preset sont désormais enveloppés dans :where().

Pseudo-états CSS dans l'éditeur

Parallèlement aux styles responsifs, WordPress 7.1 ajoute le support des pseudo-états CSS dans theme.json et l'éditeur. Les états :hover, :focus, :focus-visible et :active sont disponibles, pour l'instant uniquement sur les blocs Button et Navigation Link.

Exemple pour un bouton avec hover responsive :

"core/button": {
":hover": {
"color": { "background": "var:preset|color|contrast" }
},
"@mobile": {
":hover": {
"color": { "background": "var:preset|color|contrast-2" }
}
}
}

Une fonctionnalité expérimentale de custom states est également présente, réservée pour l'instant à theme.json sans interface utilisateurUser Interface : couche visuelle et interactive (composants, layout, états).. Elle utilise un préfixe - et génère du CSS ciblant un nom de classe déclaré via la propriété selectors.states du block.json. Le bloc Navigation Link s'en sert pour styler l'élément de menu actif via une propriété -current.

Comme pour le responsive, un réglage blockStatesEditingEnabled permet de désactiver cette fonctionnalité.

L'API SVG Icon devient publique

WordPress 7.0 avait introduit un ensemble d'icônes SVG pour l'éditeur et le bloc Icon. En 7.1, cet ensemble devient une API publique dans laquelle les développeurs peuvent enregistrer leurs propres icônes.

Chaque icône appartient à une collection, qui sert de namespace : my-plugin/star ne peut pas entrer en conflit avec core/star. L'enregistrement se fait via wp_register_icon_collection() pour la collection, puis wp_register_icon() pour chaque icône. La fonction wp_get_icon() permet de rendre une icône en PHP avec des arguments optionnels pour la taille, la classe et le label.

Deux limites à anticiper :

• Les SVG enregistrés sont nettoyés via wp_kses avec une liste blanche volontairement restrictive : seuls <svg>, <path> et <polygon> sont autorisés. Un travail est en cours pour élargir cette liste.
• L'attribut fill n'est autorisé que sur les formes, pas sur la balise <svg> elle-même, et wp_get_icon() n'en ajoute pas. Dans le bloc Icon, ce n'est pas un problème car la feuille de style du bloc définit fill sur la couleur courante. Mais un appel autonome à wp_get_icon() rend l'icône avec son propre fill (noir par défaut), pas la couleur du texte environnant. La recommandation est de fournir votre propre CSS via la classe passée en argument.

L'éditeur de posts toujours en iframe

Depuis WordPress 5.8, l'éditeur de templates fonctionne dans une iframe. En 7.1, l'éditeur de posts franchit la dernière étape : il est désormais toujours en iframe, quel que soit le type de thème, les versions d'API des blocs enregistrés ou des blocs présents dans le contenu. Les sites qui enregistrent des meta boxes héritées sont également concernés.

Dans WordPress 7.0, la décision se prenait post par post en fonction des blocs insérés, ce qui signifiait que l'éditeur pouvait basculer entre mode iframe et non-iframe selon le contenu. Ce comportement conditionnel disparaît.

La plupart des blocs fonctionnent sans modification. Les problèmes qui apparaissent proviennent presque toujours d'une même cause : l'iframe possède son propre document et window, distincts de la page d'administration où les scripts de l'éditeur s'exécutent. Le code qui accède au document ou window global pour manipuler le canvas regarde le mauvais document. Les correctifs habituels consistent à récupérer le document du canvas depuis un élément à l'intérieur via ownerDocument et defaultView, et à utiliser useRefEffect pour attacher et nettoyer les listeners sur les éléments du canvas. Le manuel technique sur l'éditeur en iframe couvre l'ensemble des considérations.

Changements dans les tables de liste

Un changement discret mais susceptible de casser du code existant : dans le changeset 62838, l'en-tête de ligne principal (th scope="row") des tables de liste de posts a été déplacé de la colonne checkbox vers la colonne titre. La cellule checkbox est désormais un td, la cellule titre devient un th portant un aria-label avec le titre du post, et les cellules repliées en vue responsive utilisent un layout flex.

C'est un gain réel pour l'accessibilité : les lecteurs d'écran identifient désormais chaque ligne par le post plutôt que par une checkbox qui peut ne pas être présente. Mais ce markup est resté largement stable depuis 2010, et de nombreuses extensions en dépendent implicitement. Vérifiez tout CSS ou JavaScript sélectionnant th.check-column, ou s'attendant à trouver les actions de ligne et les titres de posts dans un td.

Abilities API : de l'infrastructure au toolkit

L'Abilities API a été livrée comme infrastructure dans WordPress 6.9. En 7.1, elle reçoit presque tout ce qu'il faut pour construire dessus : un cycle d'exécution filtrable, une validation personnalisée et un pipeline de découverte partagé. Pour les développeurs qui construisent des intégrations IA, des outils d'automatisation ou des adaptateurs de protocole, c'est la version où l'API cesse d'être une fondation pour devenir une boîte à outils.

Cinq dev notes couvrent le sujet, à lire dans cet ordre : nouveaux filtres du cycle d'exécution, améliorations de l'Abilities API, filtrage des abilities enregistrées avec wp_get_abilities(), un flag d'exposition publique unifié, et préparation du JSON Schema pour la compatibilité client.

Design System pour les interfaces d'administration

WordPress 7.1 introduit un support de base pour thématiser les composants d'interface d'administration, couvrant couleur, arrondi et styles de curseur. Attention : cela n'a rien à voir avec le front-end. Le terme « theming » ici concerne directement l'admin.

La feuille de style wp-theme fournit un ensemble complet de tokensUnité de texte traitée par un modèle (souvent un morceau de mot). Les coûts et fenêtres de contexte se comptent en tokens. de design sémantiques sous forme de propriétés CSS personnalisées, permettant de les référencer au lieu de coder des valeurs en dur. Le handle de script wp-theme fournit un composant React ThemeProvider qui enveloppe une section de page et surcharge les valeurs de ces tokens. Donnez-lui une paire de couleurs de base et il génère une gamme harmonieuse pour vous.

Pour les auteurs de plugins qui souhaitaient que leurs écrans d'administration portent leur propre marque tout en restant cohérents avec WordPress, c'est la première véritable ouverture. La référence des tokens liste ce qui est disponible.

Composants : fin du prop __next40pxDefaultSize

Le prop __next40pxDefaultSize a terminé son parcours. Introduit en 6.7, soft-deprecated en 6.8, il devient un no-op en 7.1.

Les contrôles de formulaire s'affichent à 40px inconditionnellement, et passer __next40pxDefaultSize={false} ne permet plus de revenir à 36px. Retirez le prop de votre code ; il n'y a pas de remplacement. Si vous passiez size="__unstable-large" uniquement pour obtenir le contrôle plus haut, retirez-le également. Sur BorderBoxControl, BorderControl, FontSizePicker et ToggleGroupControl, le prop size est également déprécié.

Tooltips accessibles dans wp-admin

Les tooltips existent dans l'éditeur depuis un moment, mais pas dans le reste de wp-admin. WordPress 7.1 ajoute wp_get_tooltip() et wp_get_toggletip() pour combler ce manque. Le premier donne un nom accessible visible aux contrôles icon-only ; le second ajoute un bouton déclenchable pour un texte d'aide étendu. Core les utilise sur les contrôles de meta box de posts et la case « Se souvenir de moi » de l'écran de connexion, respectivement.

Le CSS se charge globalement, mais le JavaScript ne se charge que là où Core l'utilise. Ailleurs, enqueue wp-tooltip pour les deux.

Divers API de blocs et extensibilité

Plusieurs éléments méritent l'attention :

• Les transformations de blocs peuvent désormais cibler une variation spécifique via variationName, et switchToBlockType() accepte une variation comme troisième argument.
• __experimentalCloneSanitizedBlock et __experimentalSanitizeBlockAttributes sont stabilisés. Les noms expérimentaux fonctionnent encore mais loguent désormais des dépréciations.
• Les entités non paginées retournent désormais tous les enregistrements. Si vous obteniez une liste tronquée de dix via getEntityRecords(), vous obtenez maintenant tout, donc vérifiez partout où vous rendez sans limite propre.
• Les template parts peuvent désormais refuser l'édition content-only via le nouveau réglage disableContentOnlyForTemplateParts.

Ailleurs dans GutenbergÉditeur de blocs de WordPress (et écosystème associé) pour composer pages et contenus. 23.6 et 23.7 : les block bindings partagent l'assemblage de contexte entre les sites d'appel, les blocs PHP-only transmettent l'ID du post courant au rendu serveur, le slot de styles des contrôles d'inspecteur est revenu à sa position précédente, et PluginPostStatusInfo est désormais disponible dans le résumé de post DataForm. L'Interactivity API a également refactorisé ses directives en modules auto-enregistrables.

Filtrage des écrans du Site Editor

Quatre nouveaux filtres permettent de configurer les composants DataViews et DataForm qui alimentent les écrans Pages, Templates, Parts et Patterns :

• get_entity_view_config_posttype_page
• get_entity_view_config_posttype_wp_template
• get_entity_view_config_posttype_wp_template_part
• get_entity_view_config_posttype_wp_block

La documentation complète figure dans le Field Guide 7.1.

Ce que la source ne dit pas

Le Field Guide mentionne plusieurs fonctionnalités qui n'ont pas été intégrées à 7.1 : la collaboration temps réel n'est pas activée, le plan de masquer le bloc Classic de l'inserter a été annulé, React 19 est à nouveau reporté, le widget dashboard « On This Day » n'a pas été livré, et la proposition de fusion Guidelines/Knowledge continue d'évoluer. Pour les développeurs qui suivaient ces pistes dans les précédents roundups, c'est l'état actuel.

Deux mises à jour de sécurité ont également été publiées le mois dernier : WordPress 7.0.2 le 17 juillet (une faille critique et une haute sévérité, avec mise à jour forcée activée par WordPress.org) et WordPress 7.0.3 le 6 août (une douzaine de correctifs supplémentaires). Si un site que vous maintenez a échappé aux deux mises à jour automatiques, c'est le moment de vérifier.

Avec neuf jours avant la sortie de 7.1, c'est la dernière fenêtre confortable pour tester vos plugins et thèmes. La version trunk et la dernière release de Gutenberg sont disponibles, ou vous pouvez lancer une instance Playground sans configuration.