La sortie de WordPress 7.1 est prévue le 19 août et s’annonce comme une mise à jour passionnante pour les développeurs, les professionnels, les agences et les blogueurs de l’ensemble de l’écosystème.
Cette deuxième version majeure de l’année apporte un large éventail de nouveautés couvrant pratiquement tous les aspects du CMS. Parmi les nouvelles fonctionnalités, c’est le traitement des médias côté client qui nous enthousiasme le plus. En effet, chez Kinsta, nous accordons une importance capitale aux performances Web et à la vitesse des sites, et cette nouvelle architecture multimédia marque une avancée significative : elle apporte des améliorations notables en termes d’efficacité des serveurs et de réduction des temps de chargement des pages.
Au-delà de la gestion des médias, WordPress 7.1 apporte des améliorations notables à la collaboration en équipe, notamment de nouvelles fonctionnalités de « Notes », ainsi que plusieurs perfectionnements de l’interface utilisateur dans le tableau de bord d’administration — tels qu’une barre d’administration persistante et le nouvel écran « Identité » dans l’éditeur de site. Cette version comprend des blocs nouveaux et améliorés, des outils de conception étendus et un large éventail de mises à jour destinées aux développeurs.
Envie de découvrir les nouveautés à venir ? Plongeons-nous dans WordPress 7.1.
Traitement des médias côté client
Jusqu’à WordPress 7.0, la génération des dimensions d’image et des miniatures destinées à l’affichage sur l’interface publique, la conversion des formats et la gestion de la rotation des images étaient entièrement gérées côté serveur via PHP.
Désormais, WordPress 7.1 introduit une nouvelle architecture de traitement des médias : le redimensionnement des images, la conversion de format, la rotation EXIF et la génération de miniatures s’effectuent désormais côté client, directement dans le navigateur de l’utilisateur.
Ce changement devrait améliorer considérablement les performances du site et réduire la consommation de ressources du serveur.
Examinons de plus près les changements apportés au traitement des images :
1. Qu’est-ce que le traitement des médias côté client ?
Alors qu’auparavant les images étaient traitées sur le serveur par PHP à l’aide des bibliothèques GD ou Imagick, la génération d’images dans différentes tailles, la conversion de format et la rotation EXIF s’effectuent désormais directement dans le navigateur de l’utilisateur — à condition que ce dernier prenne en charge l’en-tête Document-Isolation-Policy (DIP) pour autoriser l’accès à SharedArrayBuffer.
Le traitement s’effectuant dans le navigateur, WordPress ne reçoit plus une seule image, mais l’ensemble des fichiers image résultant du pipeline de traitement. Cela a deux conséquences principales : une réduction de l’utilisation du processeur et de la mémoire vive du serveur, et un nombre accru de requêtes HTTP pour le téléversement des miniatures individuelles.
À la date de rédaction de cet article, seuls Chrome 137 et Microsoft Edge 137 (version bureau) prennent entièrement en charge le pipeline « Document-Isolation-Policy ». Safari et Firefox ne prennent pas en charge le pipeline WASM, bien que Safari prenne en charge le décodage natif des formats HEIC/HEIF vers le format JPG.
2. Quelles sont les caractéristiques techniques du traitement des médias côté client ?
D’un point de vue architectural, le traitement des médias côté client est géré par trois paquets principaux :
- Le nouveau module «
@wordpress/vips» gère le traitement côté client à l’aide de la bibliothèque «libvips» compilée en WebAssembly (wasm-vips). Largement considérée comme l’une des bibliothèques de traitement d’images les plus rapides et les plus efficaces du marché, elle s’exécute en parallèle au sein d’un Web Worker, ce qui empêche le gel de l’interface utilisateur et offre des performances nettement supérieures à celles du JavaScript pur. - Le package
@wordpress/upload-mediagère le pipeline de téléversement, notamment la gestion des files d’attente de téléversement, la concurrence des téléversements (jusqu’à 5 téléversements simultanés et 2 opérations de traitement d’images), les nouvelles tentatives automatiques, la reprise des téléversements interrompus et la prise en charge hors ligne. - Le module «
@wordpress/media-utils» gère le transport HTTP et les requêtes API REST.
Outre le traitement des images, cette nouvelle fonctionnalité introduit la conversion automatique des GIF animés en vidéos MP4/WebM. La conversion est gérée par le nouveau package « @wordpress/video-conversion », qui intègre la bibliothèque «mediabunny » dans un Web Worker afin de convertir les GIF opaques (sans arrière-plan transparent) en fichiers vidéo légers.
Le traitement multimédia côté client introduit également de nouveaux points de terminaison de l’API REST (sideload, finalize et replace_file) ainsi que deux nouveaux paramètres : generate_sub_sizes et convert_format.
3. Quels sont les avantages pour les utilisateurs de WordPress ?
Le traitement des médias côté client transfère la charge de traitement des images du serveur vers le client. Cela libère le serveur de la lourde charge de travail liée à la génération de miniatures de différentes dimensions, à la rotation des images et à la conversion des formats, en transférant directement cette tâche au navigateur de l’utilisateur.
Voici quelques-uns des avantages pour les utilisateurs liés au transfert du traitement des médias vers le client :
- Moins d’erreurs de mémoire insuffisante en PHP : le traitement des médias côté client élimine les erreurs de mémoire insuffisante (
PHP memory limit exceeded) qui survenaient auparavant lors du traitement de fichiers image volumineux. - Réduction de la consommation de CPU et de RAM : un autre avantage majeur pour le serveur est la réduction substantielle de l’utilisation du CPU et de la RAM de l’hôte, ce qui libère des ressources pour d’autres tâches.
- Meilleures performances du site : la bibliothèque
libvipsutilise des algorithmes de compression avancés qui produisent des images dont la taille est, en moyenne, inférieure d’environ 15 % à celle des images générées par GD ou Imagick. Cela se traduit par des images plus légères et des temps de chargement des pages plus rapides. - Meilleure résilience lors du téléversement : chaque téléversement d’image nécessite une requête HTTP indépendante. Cela entraîne un volume plus élevé de requêtes HTTP, mais garantit que chaque image est traitée de manière indépendante. Les requêtes ayant échoué sont automatiquement mises en attente et relancées.
De plus, les GIF animés peuvent être automatiquement convertis en vidéos à lecture automatique plus efficaces ; les photos HEIC téléversées depuis des iPhone peuvent être converties au format JPG par le navigateur avant leur téléversement (ce qui permet de contourner d’éventuels problèmes de compatibilité avec le serveur), et la prise en charge du format AVIF fonctionne désormais même en l’absence de capacités AVIF côté serveur (la vérification du type MIME est contournée pour les téléversements décodés côté client).
4. Quels changements pour les développeurs ?
Les développeurs peuvent désactiver le traitement des médias côté client à l’aide du nouveau filtre « wp_client_side_media_processing_enabled ». En voici un exemple :
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Au-delà de cela, il n’y a pas de perturbations majeures pour les développeurs d’extensions. Les hooks associés au traitement des médias continuent de se déclencher exactement comme si les images étaient traitées sur le serveur.
Les filtres existants lisent les réglages depuis le serveur et continuent de fonctionner comme prévu. Par exemple, le filtre ` wp_generate_attachment_metadata ` s’exécute deux fois : une première fois lors du téléversement initial (create) et une seconde fois après l’appel du point de terminaison de finalisation (update). Les plugins utilisant ce filtre continueront de fonctionner comme prévu.
Pour les développeurs de thèmes, les tailles d’image enregistrées via add_image_size() sont désormais générées côté client. Si un thème définit une taille d’image dont les dimensions sont identiques à celles d’une taille WordPress par défaut, les images sont « dédupliquées » en un seul fichier image enregistré sous les deux noms de taille.
5. Quels sont les avantages en matière de sécurité ?
Bien que le traitement des médias côté client soit principalement conçu pour améliorer les performances et l’efficacité plutôt que pour la sécurité, il offre plusieurs avantages qui renforcent la sécurité des sites WordPress.
Tout d’abord, il réduit la surface d’attaque. Comme mentionné précédemment, avant WordPress 7.1, le traitement des images s’appuyait sur des bibliothèques côté serveur telles que GD et Imagick. Au fil du temps, ces bibliothèques ont été affectées par diverses failles de sécurité liées au décodage des images.
Avec le traitement des images côté client, le serveur n’a plus besoin de GD ni d’Imagick, car il reçoit des images prétraitées. Cela réduit considérablement la quantité de code sensible exécuté sur le serveur.
Un autre avantage en matière de sécurité réside dans le fait que le traitement des images s’effectue au sein d’un environnement de navigateur isolé, à l’aide de WebAssembly dans un Web Worker.
Le traitement côté client réduit également le risque d’attaques par déni de service (DoS), car la charge de calcul repose sur le client.
Pour traiter les images côté client, WordPress s’appuie sur SharedArrayBuffer, un objet JavaScript qui permet au thread principal et aux Web Workers de partager le même espace mémoire.
Pour autoriser l’accès à SharedArrayBuffer, WordPress active l’en-tête « Document-Isolation-Policy: isolate-and-credentialless ». Cela fournit un contexte d’exécution isolé pour l’éditeur de blocs dans les navigateurs Chromium 137 (Chrome 137 et Edge 137).
En résumé, si l’objectif principal du traitement multimédia côté client est d’améliorer les performances et l’efficacité de la gestion des médias, cette nouvelle fonctionnalité apporte également des améliorations notables en matière de sécurité.
6. Ressources officielles
Le traitement des médias côté client a fait l’objet d’une documentation exhaustive destinée tant aux utilisateurs qu’aux développeurs. Consultez les ressources suivantes pour plus de détails :
- Traitement multimédia côté client dans WordPress 7.1 (note de développement)
- Architecture du traitement des médias côté client (Manuel de l’éditeur de blocs)
- Traitement des médias côté client (guides pratiques)
- Filtres et réglages du traitement des médias côté client (référence des hooks)
Améliorations apportées aux notes
Introduites pour la première fois dans WordPress 6.9, les notes ont bénéficié de nombreux ajouts et améliorations qui en font un outil de collaboration plus complet.
Tout d’abord, WordPress 7.1 ajoute la prise en charge du texte enrichi dans les notes, ce qui les rend « plus expressives, plus claires à lire et mieux adaptées aux attentes des utilisateurs vis-à-vis d’outils tels que Google Docs, Figma, GitHub et d’autres éditeurs collaboratifs ».
Cela inclut les formats de base en ligne tels que le gras (Ctrl/⌘ B), l’italique (Ctrl/⌘ I), les liens (Ctrl/⌘ K) et les emojis.
Vous pouvez désormais ajouter des notes en ligne en sélectionnant des fragments de texte plutôt qu’un bloc entier (commentaires en ligne). Il est également possible d’ajouter plusieurs notes au même bloc ou à la même sélection de texte.
WordPress 7.1 introduit également les @mentions pour taguer vos collaborateurs dans les notes, ce qui rend la fonctionnalité « Notes » plus similaire aux outils de collaboration courants. Lorsque vous tapez le caractère @, un panneau s’affiche avec la liste des utilisateurs de votre site pour faciliter la sélection. Le destinataire de la mention recevra une notification par e-mail contenant un lien vers l’article.
Une autre nouveauté concerne la partie visible des notes. Les notes longues sont désormais masquées par défaut afin de ne pas encombrer excessivement l’espace à l’écran. Un bouton « Afficher plus/ Afficher moins » vous permet d’afficher ou de masquer l’intégralité du texte.
Vous pouvez consulter la liste complète des nouvelles fonctionnalités des « Notes » incluses dans WordPress 7.1 dans la section « Notes » de la version 7.1 de WordPress.
Améliorations de l’interface utilisateur d’administration
L’interface utilisateur d’administration bénéficie de plusieurs mises à jour qui améliorent la cohérence de l’interface et simplifient la navigation entre les écrans.
Barre d’administration persistante dans l’éditeur d’articles et l’éditeur de site
Avant WordPress 7.1, la barre d’administration n’apparaissait pas dans l’éditeur de publication ni dans l’éditeur de site. Ce comportement manquait de cohérence, car la barre d’administration est l’élément le plus utilisé de l’interface d’administration, et son omission dans les éditeurs n’était pas considérée comme optimale. À partir de WordPress 7.1, ce comportement change, et la barre d’outils d’administration est désormais visible dans l’éditeur de publication et l’éditeur de site.
Extension du thème de couleurs de l’utilisateur à l’éditeur de site
Une autre amélioration visant à harmoniser l’apparence de tous les espaces d’administration consiste à appliquer à l’éditeur de site le même thème de couleurs que celui défini par l’utilisateur sur sa page de paramètres. Avant la version 7.1, la barre latérale de l’éditeur de site était systématiquement noire.
La colonne latérale de l’éditeur bénéficie également d’une mise à jour avec WordPress 7.1. L’icône du site a été supprimée de la barre d’outils de l’éditeur et apparaît désormais dans la barre d’outils de WordPress.
Dans les versions précédentes, pour revenir à l’interface d’administration de WordPress, vous deviez cliquer sur l’icône du site, qui n’était pas techniquement un bouton « Retour ».
Par conséquent, l’icône du site n’apparaît désormais que dans la barre d’outils d’administration, tandis qu’un bouton « Retour » plus clair figure dans la barre d’outils de l’éditeur.
Catégories de commandes et amélioration de l’interface utilisateur de la palette de commandes
La palette de commandes a fait l’objet de plusieurs ajouts et modifications visant à améliorer sa facilité d’utilisation. Tout d’abord, les commandes disponibles ont été réparties en sections (récentes, suggestions et résultats) afin de faciliter leur recherche.
La fenêtre modale a été redimensionnée (512 px) et les commandes sont désormais plus faciles à lire.
Écran « Identité » dans l’éditeur de site
Un nouvel élément « Identité » apparaît désormais dans le menu « Conception » de l’éditeur de site. L’écran correspondant vous permet de configurer le titre, le slogan, le logo et l’icône de votre site. Vous pouvez ainsi modifier les réglages d’identité de votre site sans quitter l’éditeur de site.
Défilement infini pour l’affichage en grille de la médiathèque
Jusqu’à WordPress 7.0, il était possible d’activer le défilement infini pour l’affichage en grille de la médiathèque via le filtre media_library_infinite_scrolling, qui était défini par défaut sur false. Les développeurs pouvaient modifier ce réglage par défaut en ajoutant la ligne suivante à leurs extensions :
add_filter( 'media_library_infinite_scrolling', '__return_true' );À partir de WordPress 7.1, le filtre ` media_library_infinite_scrolling ` est défini sur ` true `, ce qui signifie que le défilement infini dans la vue en grille de la médiathèque est activé par défaut pour tous les utilisateurs.
De plus, un nouveau réglage disponible sur la page de profil utilisateur dans l’interface d’administration de WordPress vous permet de définir vos préférences en matière de défilement infini.
WordPress enregistre le choix de l’utilisateur dans les options utilisateur à l’aide de la clé méta « infinite_scrolling ». Vous pouvez récupérer la préférence de l’utilisateur de la manière suivante :
$infinite_scrolling = get_user_option( 'infinite_scrolling', $user_id );Blocs principaux et améliorations apportées aux blocs
WordPress 7.1 introduit deux nouveaux blocs et apporte diverses améliorations aux blocs existants.
Nouveaux blocs « Liste de lecture » et « Onglets »
Un nouveau bloc « Liste de lecture » vous permet d’intégrer une liste de lecture simple dans votre contenu.
Les utilisateurs peuvent personnaliser plusieurs aspects de l’apparence du bloc, notamment la typographie, l’arrière-plan, les dimensions, la bordure et les éléments. Les commandes de style spécifiques à ce bloc comprennent « Forme d’onde et bouton de lecture » et « Arrière-plan de la forme d’onde ». La commande « Forme » vous permet de modifier la visualisation de la forme d’onde audio.
Le bloc Liste de lecture prend en charge tous les fichiers audio compatibles avec votre installation WordPress. Si vous ajoutez la prise en charge d’un nouveau type MIME, le bloc en hérite automatiquement.
Le nouveau bloc Onglets intégré au cœur du système est conçu pour organiser le contenu en onglets. Chaque onglet peut contenir n’importe quel bloc, ce qui le rend particulièrement utile pour héberger du contenu classé par thème, des FAQ ou des comparaisons de produits/services.
Blocs modifiables à l’intérieur du bloc « HTML personnalisé »
Le bloc « HTML personnalisé » a bénéficié d’une nouvelle amélioration. Vous pouvez désormais ajouter des blocs modifiables directement au sein du code HTML. Cela vous permet de combiner du code HTML statique et des blocs modifiables au sein d’un même extrait de code.
Bien qu’ils puissent être modifiés, les blocs modifiables ne peuvent ni être déplacés ni supprimés, et il n’est pas possible d’ajouter des blocs supplémentaires via l’éditeur visuel. Toutefois, le code sous-jacent reste entièrement modifiable dans l’éditeur de code.
Avant WordPress 7.1, votre contenu devait être soit entièrement en HTML statique, soit entièrement composé de blocs. Vous pouvez désormais combiner librement du code HTML et des blocs, ce qui s’avère particulièrement utile lors de la génération de contenu à l’aide de modèles d’IA.
Cette modification s’accompagne de la possibilité d’ajouter du code HTML statique aux variantes de blocs. Grâce à la nouvelle prise en charge de la balise innerContent, vous pouvez enregistrer une variante du bloc « Code HTML » comme illustré dans l’exemple ci-dessous :
wp.blocks.registerBlockVariation( 'core/html', {
name: 'custom-image-card',
title: 'Custom image card',
description: 'A custom HTML block with static header/footer and an editable image.',
innerContent: [
'<h2>Static heading</h2>\n',
null,
'\n<footer>Static footer</footer>'
],
innerBlocks: [
[
'core/image',
{
id: 419,
sizeSlug: 'medium',
linkDestination: 'none',
url: 'https://example.com/wp-content/uploads/...',
alt: ''
}
]
],
} );La valeur « null » dans « innerContent » sert d’espace réservé pour le bloc « Image ».
Veuillez noter que « innerContent » n’est disponible que pour le bloc « HTML personnalisé ». Son application aux variantes d’autres blocs n’aura aucun effet.
Améliorations apportées au système d’icônes SVG
WordPress 7.0 a introduit un nouveau bloc « Icône » et une bibliothèque d’icônes. Avec WordPress 7.1, le système de gestion des icônes dispose désormais d’une API publique, permettant d’enregistrer, d’afficher et de supprimer des icônes par programmation, ainsi que de les récupérer via l’API REST.
Enregistrement et désenregistrement des icônes
Pour enregistrer une icône ou un ensemble d’icônes, vous devez d’abord enregistrer une collection d’icônes en accrochant la nouvelle fonction ` wp_register_icon_collection() ` à l’action `init` :
function custom_icons_register_icon_collection() {
wp_register_icon_collection(
'my-icon-set',
array(
'label' => __( 'My awesome icons', 'my-plugin' ),
'description' => __( 'My personal set of icons.', 'my-plugin' ),
)
);
}
add_action( 'init', 'custom_icons_register_icon_collection' );Une collection possède un nom unique, qui la distingue des icônes du cœur du système et des autres ensembles d’icônes enregistrés par des plugins tiers. Le nom de la collection doit commencer et se terminer par une lettre minuscule et peut contenir des lettres minuscules, des chiffres, des tirets et des traits de soulignement.
Le deuxième argument de la fonction est un tableau contenant le libellé de la collection affiché dans la bibliothèque d’icônes, ainsi qu’une description facultative.
Pour supprimer une collection, utilisez la fonction ` wp_unregister_icon_collection() `. La suppression d’une collection entraîne automatiquement la suppression de toutes les icônes qui y sont associées.
Pour enregistrer une icône individuelle, utilisez la fonction ` wp_register_icon() `, comme le montre l’exemple suivant :
wp_register_icon(
'my-icon-set/motorbike',
array(
'label' => __( 'Motorbike', 'my-plugin' ),
'content' => '<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24">...</svg>',
)
);Dans l’exemple ci-dessus, nous avons enregistré une icône à l’aide d’une chaîne SVG. Vous pouvez également enregistrer une icône directement à partir d’un fichier .svg:
wp_register_icon(
'my-icon-set/motorbike',
array(
'label' => __( 'Motorbike', 'my-plugin' ),
'file_path' => plugin_dir_path( __FILE__ ) . 'icons/motorbike.svg',
)
);Il est important de noter que le code SVG est validé à l’aide de wp_kses, et que seuls les éléments <svg>, <path> et <polygon> sont actuellement autorisés. Tous les autres éléments sont filtrés, bien que la liste d’autorisations puisse être étendue à l’avenir pour inclure des éléments et attributs supplémentaires.
Pour supprimer une icône, vous pouvez utiliser la fonction wp_unregister_icon().
Mises à jour de la bibliothèque d’icônes et des blocs
La bibliothèque d’icônes a été mise à jour en conséquence et comporte désormais une colonne latérale affichant la liste des collections d’icônes enregistrées sur le site.
Le bloc « Icône » a également été mis à jour. Par défaut, le bloc affiche désormais l’icône « Info » au lieu d’un espace vide comme dans les versions précédentes. De plus, deux nouvelles commandes dans la barre d’outils du bloc vous permettent de retourner l’icône verticalement et horizontalement.
Nouveaux points de terminaison de l’API REST pour les icônes
De nouveaux points de terminaison de l’API REST en lecture seule ont également été introduits pour accéder à des collections d’icônes ou à des icônes spécifiques.
Pour les collections d’icônes, vous utiliserez les points de terminaison suivants :
GET /wp/v2/icon-collections
GET /wp/v2/icon-collections/<collection>Pour lire les icônes, vous utiliserez plutôt les points de terminaison suivants :
GET /wp/v2/icons - Introduced with WordPress 7.0.
GET /wp/v2/icons/<collection>
GET /wp/v2/icons/<collection>/<name>Un utilisateur disposant de la capacité « edit_posts » doit authentifier les requêtes.
Pour un aperçu plus détaillé du système d’icônes dans WordPress 7.1, consultez la note de développement.
Nouveaux outils de conception
Les créateurs et les éditeurs disposent désormais de nouveaux outils de conception améliorés qui leur permettent de styliser les blocs de contenu sans avoir recours à du CSS personnalisé.
Prise en charge des dégradés d’arrière-plan
WordPress 7.1 introduit la prise en charge debackground.gradient ainsi qu’un nouveau contrôle de l’interface d’administration pour les dégradés d’arrière-plan.
Dans la colonne latérale des réglages de bloc, un nouveau panneau « Arrière-plan » doté de commandes distinctes pour « Image », « Couleur » et « Dégradé » vous permet d’expérimenter différentes combinaisons d’images d’arrière-plan, de couleurs et de dégradés tout en évitant les conflits.
Dans WordPress 7.1, la prise en charge des dégradés d’arrière-plan ( background.gradient ) est activée par défaut pour les blocs « Groupe », « Accordéon », « Citation en exergue », « Contenu d’article » et « Citation ». Les développeurs de thèmes peuvent ajouter la prise en charge des dégradés d’ background.gradient dans le fichier block.json en ajoutant une propriété « gradient » sous « styles.background » ou au cas par cas pour chaque bloc, comme indiqué dans le code suivant :
{
"styles": {
"background": {
"gradient": "linear-gradient( 135deg, #1e3c72 0%, #2a5298 100% )"
},
"blocks": {
"core/group": {
"background": {
"gradient": "linear-gradient( 135deg, #f5f7fa 0%, #c3cf8d 100% )"
}
}
}
}
}Prise en charge de la largeur minimale
Une autre nouveauté de WordPress 7.1 qui ravira les concepteurs et les développeurs de thèmes est la prise en charge de la dimension « minWidth ». Celle-ci vient s’ajouter à la prise en charge existante des dimensions « height », « minHeight » et « width », complétant ainsi l’ensemble des outils de conception pour les dimensions.
Les développeurs de thèmes peuvent ajouter la prise en charge de la largeur minimale via « theme.json », soit en activant les outils d’apparence, soit en ajoutant le champ « dimensions.minWidth » dans les réglages :
{
"settings": {
"dimensions": {
"minWidth": true
}
}
}
Vous pouvez également activer la prise en charge de la largeur minimale de manière globale ou bloc par bloc :
{
"styles": {
"dimensions": {
"minWidth": "400px"
},
"blocks": {
"core/group": {
"dimensions": {
"minWidth": "400px"
}
}
}
}
}Les développeurs de blocs peuvent de la même manière ajouter la prise en charge de minWidth à block.json:
{
"supports": {
"dimensions": {
"minWidth": true
}
}
}Ce réglage est masqué par défaut dans la colonne latérale, mais vous pouvez modifier le réglage par défaut à l’aide de __experimentalDefaultControls. Dans « Styles globaux », ce réglage est visible par défaut.
Prise en charge des ombres de texte dans les « Styles globaux »
WordPress 7.1 introduit la prise en charge des ombres de texte ( text-shadow ) dans les « Styles globaux ». Auparavant, vous auriez dû utiliser une extension ou recourir à du CSS personnalisé.
Veuillez noter qu’il s’agit d’une première implémentation. Quelques décisions clés restent encore à prendre, telles que le choix du contrôle d’interface utilisateur à utiliser pour personnaliser les ombres de texte dans l’éditeur, et la question de savoir si « text-shadow » doit être disponible en tant que préréglage. Pour l’instant, il n’est possible de définir « text-shadow » dans votre fichier « theme.json » que de l’une des manières suivantes :
{
"$schema": "https://schemas.wp.org/wp/6.7/theme.json",
"version": 3,
"settings": {},
"styles": {
"typography": {
"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
},
"blocks": {
"core/paragraph": {
"typography": {
"textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
}
}
},
"elements": {
"h2": {
"typography": {
"fontSize": "var:preset|font-size|x-large",
"textShadow": "1px 1px 2em white, 0 0 2em yellow, 0 0 0.2em red;"
}
}
}
}
}L’image suivante illustre le résultat des définitions ci-dessus.
Mises à jour pour les développeurs
Les nouveautés proposées aux développeurs de thèmes et d’extensions avec WordPress 7.1 sont remarquables. Les nombreux ajouts et améliorations apportés à l’API Abilities et à la personnalisation du système de design nous semblent les plus dignes d’intérêt.
Thématisation du système de conception
WordPress 7.1 introduit un nouveau système de conception que les développeurs d’extensions peuvent utiliser pour personnaliser le style des éléments de l’interface d’administration. Ce nouveau système se compose de deux parties : les jetons de conception et un nouveau composant React ThemeProvider.
Jeton de conception
Les jetons de conception WordPress sont des propriétés CSS personnalisées qui suivent un modèle établi. Voici, par exemple, le modèle de la famille de jetons « Color » :
--wpds-color-<property>-<target>-<tone>[-<emphasis>][-<state>]Conformément au modèle ci-dessus, la variable suivante définit la couleur d’arrière-plan des surfaces présentant un niveau d’accentuation normal :
--wpds-color-background-surface-neutral-strongÀ partir de WordPress 7.1, les jetons de conception peuvent être utilisés par toute extension générant des éléments de l’interface d’administration grâce à une nouvelle feuille de style « wp-theme » qui inclut un ensemble complet de jetons de conception sémantiques et est disponible en tant que dépendance du plugin. Vous pouvez mettre en file d’attente une feuille de style personnalisée utilisant « wp-theme » comme indiqué ci-dessous :
function myplugin_enqueue_admin_assets( $hook_suffix ) {
wp_enqueue_style(
'myplugin-admin-style',
plugin_dir_url( __FILE__ ) . 'assets/css/admin.css',
array( 'wp-theme' ),
'1.0.0'
);
}
add_action( 'admin_enqueue_scripts', 'myplugin_enqueue_admin_assets' );L’avantage des jetons de conception réside dans le fait qu’ils peuvent remplacer les valeurs de propriétés CSS codées en dur. Consultez l’exemple suivant tiré de la note de développement :
.card {
background-color: var(--wpds-color-background-surface-neutral-strong);
color: var(--wpds-color-foreground-content-neutral);
border: var(--wpds-border-width-xs) solid var(--wpds-color-stroke-surface-neutral-weak);
border-radius: var(--wpds-border-radius-lg);
padding: var(--wpds-dimension-padding-2xl);
}Les jetons de conception peuvent être utilisés conjointement avec le composant ThemeProvider pour personnaliser l’apparence de zones spécifiques de la page d’administration.
ThemeProvider
Vous pouvez remplacer les valeurs par défaut des jetons de conception fournies par la feuille de style « wp-theme » en encapsulant le contenu de la zone d’administration dans le nouveau composant React « ThemeProvider », comme le montre l’exemple suivant tiré de la note de développement :
import { ThemeProvider } from '@wordpress/theme';
import { Card } from '@wordpress/ui';
function Application() {
return (
<ThemeProvider
color={
{
primary: '#3858e9',
background: '#11004d'
}
}
cornerRadius="pronounced"
>
<Card.Root>
<Card.Content>
Card content
</Card.Content>
</Card.Root>
</ThemeProvider>
);
}À partir d’une couleur principale et d’une couleur d’arrière-plan de départ, le composant génère automatiquement un dégradé harmonieux et cohérent qui assure un contraste accessible entre les éléments de l’interface utilisateur.
Le ThemeProvider permet aux développeurs d’extensions d’exprimer l’identité de leur marque au sein des zones de l’interface tout en restant cohérents avec le style général de l’interface d’administration de WordPress.
Pour une analyse plus approfondie, veuillez vous reporter à la note de développement et à la documentation officielle sur les jetons de conception et le ThemeProvider.
Améliorations apportées à l’API Abilities
Avec la sortie de WordPress 7.1, l’API Abilities bénéficie de plusieurs ajouts qui étendent ses fonctionnalités.
Nouveau cycle de vie d’exécution pour l’API Abilities
Tout d’abord, le cycle d’exécution est enrichi de 4 nouveaux filtres qui s’exécutent avant, pendant et après l’exécution d’une capacité.
Le filtre ` wp_pre_execute_ability ` s’exécute au début de ` WP_Ability::execute() ` et sert à intercepter et à interrompre l’exécution d’une action avant même que WordPress ne commence à la traiter. Si le filtre renvoie une valeur autre que la valeur par défaut ` $pre ` (une erreur, des données ou une valeur booléenne), WordPress s’arrête immédiatement, contourne les vérifications et renvoie cette valeur.
Ce filtre se prête à des cas d’utilisation intéressants, tels que la désactivation d’une fonctionnalité pendant la maintenance du site, la limitation du débit des requêtes provenant d’une même adresse IP ou la simulation de la réponse d’une fonctionnalité (tests unitaires).
Le filtre « wp_ability_normalize_input » s’exécute juste après l’application des valeurs par défaut et avant la validation formelle du schéma et les vérifications d’autorisations. Il sert à préparer ou à transformer les données entrantes avant qu’elles ne soient validées et traitées par la fonctionnalité — par exemple, pour ajouter des métadonnées contextuelles, normaliser les données avant validation, enrichir une invite d’IA ou interrompre l’exécution de la fonctionnalité en cas d’erreur.
Le filtre « wp_ability_permission_result » vous permet de modifier le résultat des vérifications d’autorisation effectuées avant l’exécution d’une fonctionnalité. Vous pouvez l’utiliser pour ajouter des règles d’autorisation plus précises, créer un système d’autorisations personnalisé ou contourner les autorisations dans des cas spécifiques.
Veuillez noter que vous devez utiliser ce filtre avec prudence :
Les extensions doivent faire preuve d’une prudence particulière avec ce filtre, car le fait de renvoyer «
true» peut remplacer un refus provenant dupermission_callbackd’origine de la capacité.
Le filtre ` wp_ability_execute_result ` s’exécute après le rappel d’exécution de la capacité et avant la validation de la sortie, ce qui vous permet de modifier le résultat final renvoyé par une capacité. Il vous permet de transformer la réponse générée par le traitement de la capacité avant qu’elle ne soit renvoyée à l’appelant.
Filtrage et manipulation des capacités
Avant WordPress 7.1, le filtrage des capacités enregistrées nécessitait de parcourir manuellement le registre à l’aide de la fonction ` array_filter()`. À partir de WordPress 7.1, la fonction ` wp_get_abilities() ` accepte un tableau facultatif d’arguments permettant de filtrer les capacités enregistrées selon les critères ` category `, ` namespace `, ` meta` ou une combinaison de ceux-ci.
L’exemple suivant montre comment récupérer les capacités appartenant à une catégorie spécifique :
$abilities = wp_get_abilities(
array(
'category' => 'content-generation',
)
);Vous pouvez également combiner plusieurs paramètres :
$abilities = wp_get_abilities(
array(
'category' => 'content-generation',
'meta' => array(
'public' => true,
),
)
);Pour un filtrage plus avancé, l’API fournit les paramètres item_include_callback et result_callback — deux fonctions de rappel utilisées pour inclure ou exclure des capacités du tableau et pour trier ou manipuler l’ensemble des résultats avant qu’il ne soit renvoyé.
Parallèlement aux mises à jour apportées à wp_get_abilities(), WordPress 7.1 introduit deux nouveaux filtres globaux :
wp_get_abilities_item_include: s’exécute pour chaque capacité qui passe les filtres déclaratifs etitem_include_callback. Vous pouvez utiliser ce filtre pour inclure ou exclure des capacités spécifiques à l’échelle du site.wp_get_abilities_result: s’exécute aprèsresult_callback. Vous pouvez l’utiliser pour manipuler l’ensemble des capacités sur l’ensemble du site.
Veuillez vous reporter à la note de développement pour obtenir un aperçu plus détaillé des mises à jour apportées à la fonction wp_get_abilities() et à ses filtres associés.
Nouvel indicateur d’exposition publique
WordPress 7.1 introduit également un nouvel indicateur de métadonnées permettant de signaler qu’une capacité est accessible à des clients externes, tels que l’API REST, les adaptateurs MCP et les agents IA.
Lors de l’enregistrement d’une capacité, vous pouvez désormais utiliser ` meta.public ` pour permettre à votre capacité d’être découverte et invoquée via les points de terminaison REST des capacités. Auparavant, vous deviez spécifier l’exposition séparément pour chaque canal — par exemple, en définissant « ‘show_in_rest’ => true » pour rendre une capacité visible via REST.
Autres améliorations apportées à l’API Ability
Outre les mises à jour mentionnées ci-dessus, WordPress 7.1 introduit d’autres améliorations couvrant divers aspects de l’API.
Deux nouveaux filtres, wp_ability_validate_input et wp_ability_validate_output, permettent aux extensions de valider les données d’entrée et de sortie à l’aide de règles plus complexes que celles pouvant être exprimées par le schéma JSON de WordPress. Le premier filtre s’exécute une fois que les données d’entrée ont été préparées et que la validation initiale du schéma a abouti. Le second filtre s’exécute après l’exécution de la fonctionnalité et avant que le résultat final ne soit renvoyé.
L’action « wp_ability_invoked » s’exécute au début de WP_Ability::execute() et peut être utilisée pour suivre et consigner chaque tentative d’appel d’une capacité. Vous pouvez vous accrocher à cette action pour consigner les tentatives d’accès à une capacité spécifique, mesurer la charge du serveur, mettre en place des compteurs d’utilisation quotidiens ou mensuels, et détecter les tentatives d’appels par force brute.
Attention toutefois :
L’action reçoit des données brutes, non normalisées. Les extensions doivent donc éviter de consigner les données d’entrée de manière indiscriminée, car celles-ci peuvent contenir des identifiants, des informations personnelles ou d’autres données sensibles.
Autres nouveautés pour les développeurs
Les mises à jour destinées aux développeurs ne s’arrêtent pas là. WordPress 7.1 apporte un nombre impressionnant d’améliorations et d’ajouts, offrant des outils de développement nouveaux et plus fiables. Avec cette nouvelle version, vous trouverez également :
- Quatre nouveaux filtres pour configurer les écrans de l’éditeur de site
- L’éditeur de publication toujours intégré dans un iframe
- Des mises à jour des composants de l’éditeur
- Mise à jour de jQuery UI vers la version 1.14.2
- Préparation du schéma JSON pour assurer la compatibilité avec les clients.
- Les utilisateurs peuvent désormais appliquer des styles aux pseudo-états.
- Styles de blocs adaptatifs et fenêtres d’affichage configurables
- Nouvelles fonctions pour l’affichage des infobulles et de l’aide informative
Un hébergement de nouvelle génération pour un WordPress de nouvelle génération
WordPress 7.1 marque une avancée majeure pour le CMS à plusieurs égards.
Le traitement des médias côté client représente un tournant dans la gestion des images. Le traitement s’effectue désormais côté client, ce qui se traduit par une meilleure efficacité des ressources serveur et des performances de page plus rapides.
En ce qui concerne les capacités d’IA, après les mises à jour révolutionnaires des versions 6.9 et 7.0, WordPress 7.1 marque une phase de consolidation. L’API Abilities bénéficie de nouvelles fonctionnalités qui permettent aux développeurs de créer des intégrations et des capacités d’IA plus fiables et plus sécurisées.
Une autre nouveauté puissante que les développeurs et les agences apprécieront est le « Theme Provider », qui permet aux extensions d’exprimer leur identité de marque dans l’espace d’administration tout en restant cohérents avec l’interface du tableau de bord WordPress.
On note également des améliorations apportées aux « Notes », de nouveaux blocs, un système d’icônes SVG plus performant, et bien plus encore. En bref, WordPress est loin de ralentir et est plus tourné vers l’avenir que jamais.
Pour un CMS de plus en plus avancé, il est essentiel de choisir un hébergeur qui suive le rythme des technologies modernes. Kinsta offre l’environnement idéal pour les sites WordPress de nouvelle génération : une infrastructure cloud conteneurisée, des performances exceptionnelles, une sécurité à toute épreuve et une assistance rapide et très bien notée.
Si vous n’avez pas encore essayé notre hébergement, profitez de l’essai gratuit sur certains plans ou contactez-nous pour en savoir plus.
Carlo est un passionné de webdesign et de développement frontend. Il joue avec WordPress depuis plus de 10 ans, notamment en collaboration avec des universités et des établissements d'enseignement italiens et européens. Il a écrit des dizaines d'articles et de guides sur WordPress, publiés à la fois sur des sites web italiens et internationaux, ainsi que dans des magazines imprimés. Vous pouvez trouver Carlo sur X et LinkedIn.
