Nouveautés de WordPress 5.8 (Full Site Editing, images WebP, styles et réglages globaux, et bien plus encore)

WordPress 5.8 « Tatum » est arrivé et il s’agit d’une version importante. Outre le nombre incroyable de fonctionnalités, d’améliorations et de corrections de bugs, WP 5.8 introduit une nouvelle façon de construire des sites web en apportant les premières fonctionnalités relevant du projet plus large connu sous le nom de Full Site Editing.

Outre le Full Site Editing (édition complète du site), WordPress 5.8 apporte des tonnes de changements et d’améliorations dans plusieurs domaines du CMS.

Les utilisateurs de WordPress qui n’utilisent pas l’extension Gutenberg trouveront des fonctionnalités et des améliorations provenant de neuf versions de Gutenberg au total (pour une plongée en profondeur dans chaque version, voir Gutenberg 9.9, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5, 10.6, 10.7).

Une nouvelle fonctionnalité importante pour les utilisateurs soucieux des performances de leurs sites est la prise en charge du format WebP.

Les développeurs apprécieront certainement le retrait d’IE11 de la liste des navigateurs pris en charge, le nouveau mécanisme de configuration et de style des blocs basé sur theme.json, le système amélioré d’enregistrement des blocs basé sur block.json, et les nombreuses améliorations de l’API qui seront apportées par la deuxième version de WordPress de 2021.

Ne bougez pas, car il s’agit d’un long tour d’horizon des fonctionnalités et des améliorations qui ouvrent la voie à de nouveaux outils puissants de création de sites, dont la sortie est prévue dans les mois à venir.

Fonctionnalités complètes du Full Site Editing dans WordPress 5.8

La vision derrière le Full Site Editing est de fournir une collection d’outils et de fonctionnalités permettant aux utilisateurs de WordPress de construire un site web entier en utilisant des blocs. Avec le Full Site Editing, nous verrons de nombreux blocs disponibles pour créer n’importe quel élément sur la page, des menus de navigation à l’image de marque du site, des widgets de colonne latérale, des modèles, et bien plus encore.

Même si WordPress 5.8 introduit plusieurs fonctionnalités relevant du Full Site Editing (FSE), il ne faut pas s’attendre à voir un environnement visuel de création de sites entièrement fonctionnel. FSE est encore un travail en cours, et la sortie de WordPress 5.8 ouvre une sorte de phase bêta publique. Selon Josepha Haden Chomphosy :

Le Full Site Editing est un ensemble de projets qui, ensemble, représentent un changement important, sans doute trop important pour une seule version. Le contexte le plus important à partager est qu’il ne s’agit pas d’une expérience complète et par défaut pour les utilisateurs. L’un des retours les plus clairs du processus de fusion de la phase 1 était qu’il n’y avait pas assez de temps pour les agences, auteurs de thèmes, développeurs d’extensions, constructeurs de sites, etc.

En gardant cela à l’esprit, ce processus de fusion ne sera pas un interrupteur marche/arrêt. L’accent n’est pas mis sur une expérience utilisateur complète et nuancée, mais plutôt sur une version bêta publique ouverte dans WordPress 5.8.

Ainsi, WordPress 5.8 ne présente pas une expérience FSE parfaite et complète pour le moment. Au contraire, nous verrons de nouvelles fonctionnalités ajoutées et améliorées au fil du temps, à partir de la version 5.8. Pour la même raison, nous pouvons présumer que WordPress 5.8 n’aura pas un impact considérable sur la façon dont nous avons l’habitude de créer des sites web.

À l’heure où nous écrivons ces lignes, les propriétaires et les administrateurs de sites doivent encore opter consciemment pour le FSE en installant un thème à blocs, tel que Twenty-Twenty One Blocks (la version à blocs de Twenty-Twenty One), et en activant l’extension Gutenberg.

Le Full Site Editing englobe une série de sous-projets distincts, notamment l’éditeur de site, les styles globaux, le bloc de requête, le bloc de navigation, les modèles, les blocs de thèmes, et bien plus encore. Mais ce qui se rapproche le plus du Full Site Editing dans WordPress 5.8, c’est le mode d’édition de modèles et les blocs de thèmes correspondants disponibles dans ce mode, comme nous le verrons plus loin dans cet article.

Ensuite, nous allons nous plonger dans certaines fonctionnalités du FSE qui ont été intégrées au cœur avec WordPress 5.8.

Mode d’édition des modèles

Le mode d’édition des modèles permet de créer des modèles d’articles et de pages à l’aide de blocs. Il s’agit d’un excellent moyen de réduire la complexité de la création de sites, en permettant aux utilisateurs de profiter de plusieurs fonctions d’édition de sites en dehors de l’interface de l’éditeur de sites tout en s’habituant à travailler avec des blocs. C’est également une excellente solution pour les utilisateurs qui n’utilisent pas de thèmes basés sur des blocs mais qui recherchent tout de même un moyen facile de créer et de modifier des modèles à partir de l’interface utilisateur de l’éditeur de blocs.

La personnalisation des thèmes n’a jamais été aussi facile sur WordPress. Maintenant, vous n’avez plus besoin de construire un thème enfant pour créer vos modèles personnalisés. La bonne nouvelle, c’est qu’avec WordPress 5.8, l’édition de modèles n’est pas limitée aux thèmes de blocs mais est également disponible pour les thèmes classiques.

Pour créer un nouveau modèle, il suffit d’activer le mode d’édition des modèles dans la colonne latérale des réglages. Un nouveau panneau Modèle est désormais disponible pour permettre aux utilisateurs de changer de mode d’édition (voir la note de version de Gutenberg 10.5).

Dans le panneau Modèle, vous pouvez créer un nouveau modèle ou modifier un modèle existant.

Pour créer un nouveau modèle, cliquez sur Nouveau. Saisissez ensuite un nom de modèle dans la modale et cliquez sur Créer, et vous êtes prêt.

En mode d’édition de modèle, vous pouvez construire vos modèles en utilisant tous les blocs disponibles, y compris les blocs FSE comme le titre du site, le slogan du site, la connexion/déconnexion, et bien d’autres.

Une fois que vous êtes satisfait de vos modifications, vous pouvez revenir au mode d’édition des articles et enregistrer le modèle séparément du contenu de l’article/de la page, comme le montre l’image ci-dessous :

Les modèles sont stockés dans votre base de données WordPress en tant que types de publications personnalisés nommés wp_template. Cela vous permet non seulement de modifier un modèle depuis l’interface de l’éditeur, mais aussi de les importer ou de les exporter à volonté. Vous pouvez également utiliser un modèle sur différents sites web (au moment de la rédaction de cet article, cette fonctionnalité n’est disponible que si vous activez l’extension Gutenberg).

Le mode d’édition des modèles est encore un peu bogué au moment où nous écrivons ces lignes, comme le signalent cet appel à tests et cette expérience de Justin Tadlock.

Mais il suffit d’un peu de patience et d’attendre que les principaux problèmes soient résolus pour comprendre pleinement comment le mode d’édition de modèles va changer la façon dont vous personnalisez l’aspect et la convivialité de vos sites web.

Les utilisateurs n’auront plus besoin de compétences de développeur pour avoir un contrôle total sur la mise en page et l’apparence générale du site.

Le mode d’édition de modèles était initialement disponible à la fois pour les thèmes de blocs et les thèmes classiques. Après une discussion approfondie sur le canal des responsables de la 5.8, il a été décidé d’activer l’éditeur de modèles pour les thèmes classiques et de le désactiver pour les thèmes de blocs (voir également #32858).

Selon Carolina Nymark :

Initialement, l’édition de modèles était activée pour tous les thèmes. Les développeurs de thèmes se sont inquiétés du fait qu’ils ne pouvaient pas mettre à jour tous leurs thèmes classiques existants pour prendre en charge cette nouvelle fonctionnalité. Avec un changement tardif, l’équipe de publication et l’équipe d’édition ont choisi de changer l’édition de modèle pour être opt-in pour les thèmes classiques.

Pour que les thèmes classiques soient pris en charge, les développeurs doivent maintenant ajouter le support des thèmes :

add_theme_support( 'block-templates' );

Les thèmes classiques qui utilisent theme.json peuvent se désengager en supprimant la prise en charge du thème :

remove_theme_support( 'block-templates' );

Pour un aperçu plus détaillé du fonctionnement du mode d’édition des modèles dans WordPress 5.8 et quelques exemples utiles d’utilisation, assurez-vous de regarder cette vidéo d’Anne McCarty :

Blocs de thèmes

Comme mentionné précédemment, FSE n’est pas une fonction unique mais un ensemble complet de fonctions de construction de sites qui ne sont pas uniquement liées à l’éditeur de site. Le mode d’édition des modèles n’en est qu’un exemple. Mais avec le mode d’édition des modèles, WordPress 5.8 apporte également de nombreux blocs de thème qui peuvent afficher des informations récupérées dynamiquement dans la base de données. Certains de ces blocs peuvent également être utilisés dans des contextes non-FSE (voir le problème #28744).

Les blocs de thème apportent des fonctionnalités de balises de modèle aux thèmes classiques, et vous pouvez les utiliser de la même manière que les blocs ordinaires. Par exemple, vous pouvez ajouter des étiquettes d’article ou l’image mise en avant de l’article n’importe où dans le contenu de l’article ou le modèle. Pour avoir une idée du nombre de blocs de thème ajoutés au cœur de WordPress 5.8, il suffit de saisir /post dans l’espace réservé aux blocs :

Un bloc de thème utile disponible avec WordPress 5.8 est le bloc Connexion/Déconnexion, qui fournit des liens de connexion et de déconnexion. Il peut éventuellement afficher le formulaire de connexion au lieu d’un lien. Les administrateurs de sites peuvent également personnaliser la cible de la redirection (voir PR #29766).

Pour une vue plus détaillée des blocs FSE, consultez « Activer le Full Site Editing dans les thèmes classiques » sur Github.

Le bloc boucle de requête

Combien de fois vous êtes-vous retrouvé dans une situation où vous avez besoin d’afficher une liste personnalisée d’articles de blog ou de types de publications personnalisés ? Pensez aux produits, aux événements, à l’immobilier… Bien sûr, vous avez des tonnes d’extensions à choisir pour cela, mais la possibilité de créer des requêtes hautement personnalisées nécessite souvent des compétences de développeur pour se débrouiller avec la boucle WordPress.

Avec l’introduction du bloc Boucle de requête dans le cœur de WordPress, les propriétaires de sites et les administrateurs peuvent créer des listes d’articles et de CPT sans avoir à écrire de code complexe ou à engager un développeur, du moins dans les cas d’utilisation les plus courants.

Alors, que fait le bloc de boucle de requête ?

En bref, il effectue le même travail que la boucle WordPress, mais dans le contexte visuel de l’éditeur de blocs.

Le bloc de boucle de requête effectue une requête basée sur les réglages de l’utilisateur sur la base de données WordPress, boucle sur chaque publication récupérée et affiche les données sur la page.

Après un développement intensif, ce bloc a atteint sa structure actuelle et se compose désormais de deux blocs imbriqués : les blocs Requête et Modèle de publication.

Étant donné qu’il s’agit d’une fonctionnalité avancée, le bloc Boucle de requête nécessite quelques configurations.

Tout d’abord, vous pouvez choisir entre différents modèles de blocs répertoriés dans les vues Carrousel et Grille. Une fois que vous avez choisi votre modèle, il vous suffit de cliquer sur Choisir, et le bloc de Boucle de requête génère votre liste personnalisée de publications.

Si vous cliquez sur Partir de zéro, vous verrez une liste de quatre variations du bloc du cœur : Titre et date ; Titre et extrait ; Titre, date et extrait ; et Image, date et titre (voir les composotions sur la configuration des blocs).

Une fois en place, la sélection du bloc Boucle de requête affiche la colonne latérale des réglages du bloc, dans laquelle vous pouvez créer votre requête. Vous pouvez soit hériter de la requête de l’URL, soit personnaliser les arguments de la requête : le type de publications à inclure dans la liste, l’ordre d’affichage et la présence ou non de publications épinglées.

Vous pouvez également définir plusieurs filtres, en choisissant parmi les catégories, les auteurs et les mots-clés.

En outre, un bouton Réglages d’affichage dans la barre d’outils du bloc offre davantage de réglages pour contrôler le nombre d’éléments par page, le décalage et le nombre maximum de pages à afficher.

Oui, le bloc Boucle de requête est un outil puissant, qui permet aux propriétaires de sites de créer des listes hautement personnalisées d’articles et des types de publications personnalisés.

Mais si vous vous promenez dans les réglages de la classe WP_Query, il est clair que le niveau de personnalisation possible en utilisant le code est beaucoup plus granulaire que ce qui est possible en utilisant le bloc Boucle de requête.

Néanmoins, il s’agit d’un outil précieux et flexible qui se prête à de nombreux cas d’utilisation, et nous verrons très probablement d’autres améliorations à l’avenir.

Vue de liste persistante dans l’éditeur de publication

Une autre fonctionnalité du FSE étendue à l’éditeur de publication est la vue de liste persistante. Avant WordPress 5.8 (et Gutenberg 10.7), la vue en liste était affichée dans un popover. En déplaçant le focus en dehors du popover, la liste disparaissait.

À l’inverse, l’éditeur de site affichait la vue en liste dans une colonne latérale contenant l’ensemble de l’arborescence du bloc.

Avec WordPress 5.8, la vue en liste s’affiche désormais dans une colonne latérale de l’éditeur de publication, ce qui permet aux utilisateurs de naviguer plus rapidement et plus précisément dans l’arborescence des blocs.

Si vous cliquez sur un élément de la vue en liste, celui-ci est mis en évidence et le focus est déplacé vers le bloc correspondant dans le canevas de l’éditeur de publications. En outre, si vous survolez les éléments de la vue en liste, l’élément et le bloc correspondant dans l’éditeur de publications sont mis en évidence.

Enfin, l’ajout d’une ancre à un bloc apparaîtra également à côté de l’élément correspondant dans la vue en liste.

Avec toutes ces améliorations apportées à la vue en liste, la navigation dans les documents complexes devrait être beaucoup plus facile.

Éditeur de widgets à base de blocs et widgets à base de blocs dans l’outil de personnalisation

L’éditeur de widgets basé sur les blocs est un vaste projet visant à apporter l’interface de l’éditeur de blocs aux thèmes à widgets classiques.

Le nouvel éditeur de widgets offre de nombreux avantages à la grande majorité des personnes qui utilisent encore des thèmes classiques. En même temps, il leur permet de se familiariser avec l’interface des blocs avant qu’elle ne devienne la norme pour tous les utilisateurs de WordPress.

Comme le souligne Anne McCarty, les widgets basés sur des blocs présentent plusieurs avantages, dont les suivants :

• Vous pouvez désormais créer des mises en page dans les colonnes latérales, les en-têtes et les pieds de page à l’aide de colonnes, de séparateurs et d’autres blocs de conception.
• Les widgets prennent désormais en charge l’édition de texte enrichi par défaut, sans que les utilisateurs aient besoin d’ajouter un code personnalisé ou d’intégrer un éditeur HTML tiers avec une extension.
• De nombreux widgets basés sur des codes courts sont désormais disponibles sous forme de blocs, ce qui simplifie l’expérience d’édition.

Andrei Draganescu souligne également les avantages que nous pouvons tirer de la possibilité de modifier des widgets à partir d’une interface basée sur des blocs :

Le principal avantage de la mise à niveau de la fonctionnalité des widgets vers les blocs réside dans la possibilité de modifier directement les widgets en utilisant l’interaction familière des blocs que vous utilisez lorsque vous modifiez une page ou un article sur votre site. La possibilité d’utiliser des blocs ouvre des tonnes de nouvelles possibilités créatives, des mini mises en page sans code à l’exploitation de la vaste bibliothèque de blocs du cœur et de blocs tiers pour créer du contenu.

Vous n’avez pas à craindre que vos widgets cessent de fonctionner avec WordPress 5.8, car la communauté a travaillé dur pour assurer la rétrocompatibilité afin que « les widgets existants et les widgets tiers continuent de fonctionner et puissent être utilisés avec les blocs » (voir Éditeur de widgets basé sur les blocs dans WordPress 5.8).

Mais là encore, pour éviter tout problème de compatibilité avec votre installation WordPress existante, n’oubliez pas de tester la nouvelle version dans un environnement de staging avant de mettre à jour votre site en production.

Pour ceux d’entre vous qui ne souhaitent pas utiliser l’éditeur de widgets basé sur des blocs pour le moment, il est toujours possible de restaurer l’écran classique des widgets de trois manières différentes :

1. 1. Vous pouvez installer l’extension officielle Classic Widgets, qui rétablit l’ancienne interface de l’écran des widgets. L’extension « sera prise en charge et maintenue au moins jusqu’en 2022, ou aussi longtemps que nécessaire ».
   2.  Les développeurs de thèmes peuvent désactiver l’éditeur de widgets basé sur des blocs en supprimant la prise en charge du thème comme suit :

      remove_theme_support( 'widgets-block-editor' );

   3.  Un nouveau filtre use_widgets_block_editor peut également être utilisé :

      add_filter( 'use_widgets_block_editor', '__return_false' );

Voir aussi Rétablir l’éditeur de widgets classique dans Vue d’ensemble de l’éditeur de blocs de widgets.

Bloquer les widgets dans l’outil de personnalisation

Dans le cadre du même projet, WordPress 5.8 apporte également des blocs de widgets dans l’outil de personnalisation.

L’ajout d’un widget basé sur un bloc dans la personnalisation est assez simple. Vous pouvez lancer l’insertion de widgets de personnalisation en cliquant sur l’icône plus dans le coin supérieur droit du panneau des widgets.

Vous pouvez également lancer l’insertion rapide depuis le bas du panneau des widgets, comme le montre l’image suivante.

Au moment de la rédaction de cet article, la nouvelle interface de modification des widgets nécessite encore des améliorations et des corrections de bogues, mais les possibilités de personnalisation sont pratiquement illimitées.

En gros, à partir de WordPress 5.8, vous disposerez de la puissance de l’éditeur de blocs dans l’outil de personnalisation, et vous pourrez sans problème créer des colonnes latérales hautement personnalisées.

.

La dev-note sur l’éditeur de widgets basé sur des blocs offre un aperçu plus approfondi de l’éditeur de widgets basé sur des blocs, avec des exemples et des ressources pour les développeurs.

Fonctionnalités et améliorations de l’éditeur de blocs

Outre la première mise en œuvre du FSE, WordPress 5.8 apporte également de nouvelles fonctionnalités et des améliorations à plusieurs éléments de l’éditeur de blocs, ce qui améliore considérablement l’expérience d’édition globale.

Ces changements comprennent :

Améliorations des blocs Média et texte

La transformation d’un bloc en bloc colonnes est possible depuis un certain temps déjà. Cependant, tous les blocs transformés en blocs colonnes ont une seule colonne. Cela pourrait conduire à des résultats sous-optimaux pour le bloc Média et texte, pour lequel une seule colonne n’est généralement pas adaptée.

À partir de WordPress 5.8 (et Gutenberg 10.2), la transformation du bloc Média et texte en bloc Colonnes ajoute automatiquement deux colonnes : une pour l’image et une autre pour le texte.

Améliorations des blocs réutilisables

Les blocs réutilisables permettent à l’utilisateur d’enregistrer un bloc ou un groupe de blocs pour le réutiliser ultérieurement dans n’importe quel article ou page d’un site web. Ceci est surtout utile pour les utilisateurs qui incluent de manière répétée le même bloc ou groupe de blocs dans différents articles/pages.

Avec WordPress 5.8, les blocs réutilisables sont visuellement plus clairs, ce qui les rend plus faciles à gérer pour les utilisateurs de WordPress.

Voici une liste rapide des améliorations des blocs réutilisables que les utilisateurs trouveront après avoir mis à jour leurs sites web vers WordPress 5.8 :

• Lors de la création d’un bloc réutilisable, une modale permet désormais aux utilisateurs d’attribuer un nom au bloc.
• Le nom du bloc réutilisable est désormais affiché dans la barre d’outils du bloc, la liste de navigation et le fil d’Ariane.
• Lorsqu’un bloc enfant est sélectionné, les blocs réutilisables sont désormais mis en évidence. Il s’agit d’une amélioration significative de l’ergonomie, car elle vous permet d’identifier facilement le bloc parent et son contenu.
• Il est désormais possible de modifier le nom du bloc dans l’inspecteur de la colonne latérale..

Barre d’outils du bloc d’images normalisées

Plusieurs barres d’outils de blocs ont été réorganisées afin de fournir une interface utilisateur cohérente entre les blocs et d’améliorer l’expérience utilisateur. Désormais, les commandes de la barre d’outils sont regroupées selon l’ordre sémantique « meta, block-level, inline ».

Depuis Gutenberg 10.1 et Gutenberg 10.3, tout un ensemble de barres d’outils de bloc a été normalisé. Il s’agit notamment d’une image, d’un bouton, de boutons, d’une liste, d’un titre, d’un paragraphe, d’une citation, d’un fichier audio, d’un fichier média et texte, d’une vidéo et plus encore.

Selon Matias Ventura :

Les regroupements sémantiques que nous avons dans la barre d’outils – méta, niveau de bloc, en ligne – devraient également avoir une représentation visuelle avec les bordures. À l’heure actuelle, les contrôles de niveau bloc distincts ont des représentations différentes, y compris dans des cas comme celui de la navigation, où tous les contrôles ont des bordures.

Ainsi, depuis WordPress 5.8, la barre d’outils des blocs regroupe les contrôles dans des segments entourés de bordures. En outre :

• Le segment Meta contient des commandes de type bloc, telles que le sélecteur de bloc, la poignée de déplacement et la commande de déplacement.
• Le segment de niveau de bloc contient des outils de bloc spécifiques affectant l’ensemble du contenu, tels que l’alignement dans un bloc de paragraphe ou la liaison dans un bloc d’image.
• Le segment Niveau en ligne/Autres contient des outils de transformation en ligne, tels que le formatage en ligne dans un bloc de texte.
• Le menu Plus comprend des outils supplémentaires.

L’image ci-dessous compare la barre d’outils du bloc Image dans WordPress 5.7 et 5.8 :

Améliorations de la barre haute d’outils

Lorsque le mode barre haute d’outils était activé dans les versions précédentes de WordPress, la barre haute d’outils et la barre d’outils de bloc étaient affichées côte à côte, comme le montre l’image suivante :

Avec WordPress 5.8, l’activation de l’affichage de la barre haute d’outils fixera la barre d’outils du bloc en haut de l’éditeur, juste en dessous de la barre haute d’outils. Cela se produit indépendamment de la largeur du navigateur et devrait améliorer considérablement l’expérience utilisateur.

Cette amélioration apporte également des changements pour les développeurs car elle unifie les API des barres d’outils sous le composant <BlockTools /> (voir PR #31134)

PDFs intégrés

Lorsqu’un fichier PDF est ajouté au document par le biais du bloc fichier, un nouveau bouton à bascule dans la colonne latérale vous permet d’activer/désactiver une version PDF intégrée (voir PR #30857).

Vous pouvez faire glisser le fichier directement sur le canevas de l’éditeur ou simplement le sélectionner dans la bibliothèque. Il est également possible d’ajuster manuellement la hauteur de la visionneuse PDF ou d’utiliser la commande de la colonne latérale.

Tous les principaux navigateurs web prennent en charge la visionneuse de PDF, à l’exception des navigateurs mobiles.

Prise en charge du bloc Duotone

L’une des fonctionnalités les plus intéressantes intégrées dans le cœur avec WordPress 5.8 est le filtre duotone, introduit pour la première fois avec Gutenberg 10.6.

Disponible en tant que fonctionnalité « prise en charge de bloc », le filtre duotone est activé par défaut dans les blocs d’images et de couverture. Dans le bloc de couverture, cependant, il ne fonctionne pas avec les arrière-plans fixes.

Les barres d’outils des blocs image et couverture affichent désormais une commande Appliquer un filtre duotone qui présente un sélecteur duotone avec de nombreux préréglages.

Deux sous-contrôles permettent de personnaliser séparément les ombres et les mises en évidence. L’effet est appliqué avec un filtre SVG masqué avec des styles en ligne et appliqué à l’aide d’un nom de classe spécifique

Ce nouvel outil s’accompagne d’une nouvelle propriété color.__experimentalDuotone, qui permet aux développeurs d’ajouter le filtre duotone à des blocs ou à des parties de blocs dans leur fichier block.json (pour en savoir plus, consultez la référence à l’objet couleur) :

supports: {
	color: {
		__experimentalDuotone: '> .duotone-img, > .duotone-video',
		background: false,
		text: false
	}
}

Lorsqu’un bloc déclare la prise en charge de color.__experimentalDuotone, un attribut style peut être utilisé pour définir des couleurs par défaut personnalisées :

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				duotone: [
					'#FFF',
					'#000
				]
			}
		}
	}
}

Ci-dessous, vous pouvez voir la même image avec deux effets différents de duotone appliqués:

Les développeurs peuvent définir des préréglages duotone dans le fichier theme.json (voir la section suivante), comme le montre l’extrait suivant :

{
"version": 1,
"settings": {
	"color": {
		"duotone": [
			{
				"colors": [ "#000", "#7f7f7f" ],
				"slug": "black-and-white",
				"name": "dark-grayscale"
			}
		],
	...

Vous pouvez en savoir plus sur les filtres duotone dans la rubrique Coloration de vos images avec les filtres duotone.

Couleurs et bordures des blocs de tableau

WordPress 5.8 apporte également quelques améliorations au bloc Tableau, notamment un meilleur contrôle des couleurs d’arrière-plan et d’avant-plan des tables.

Un autre ajout au bloc Tableau est la prise en charge de la bordure du bloc, qui donne aux utilisateurs la possibilité de contrôler la couleur, le style et la largeur de la bordure.

Si le thème actif prend en charge la nouvelle fonctionnalité, un nouveau panneau de réglages de bordure fournit trois nouveaux contrôles pour les personnalisations de l’utilisateur.

Les développeurs peuvent ajouter la prise en charge des bordures de blocs à leurs thèmes en ajoutant le code suivant au fichier theme.json :

"border": {
	"customColor": true,
	"customStyle": true,
	"customWidth": true
}

Améliorations apportées à l’outil d’insertion de blocs

Dans WordPress 5.8, l’outil d’insertion de blocs a été amélioré avec plusieurs ajouts (PR #26938 et #21080) :

1. Navigation bi-dimensionnelle au clavier sur l’insertion de blocs. Nous pouvons désormais naviguer entre les blocs de manière plus précise et plus intuitive.

• En appuyant sur la flèche vers le haut (↑) et la flèche vers le bas (↓), vous déplacez le focus sur la rangée supérieure ou inférieure.
• En appuyant sur la touche Tab ou sur Maj + Tab, vous pouvez déplacer le curseur entre la boîte de recherche, la liste des onglets et le premier élément de chaque catégorie.

2. Une nouvelle catégorie « Thème »pour les parties et les variations de modèles apparaît maintenant dans l’outil d’insertion du FSE (voir PR #30020).

3. Les mots multiples sont maintenant autorisés dans la recherche de phrases autocomplètes (voir PR #29939).

Améliorations supplémentaires de l’éditeur de blocs

WordPress 5.8 apporte des tonnes de petits et moyens changements supplémentaires qui méritent qu’on leur consacre quelques lignes. Parmi ces améliorations, nous citerons les suivantes :

Prise en charge du glisser-déposer dans les blocs de couverture

Vous pouvez désormais glisser et déposer des images depuis votre bureau pour remplacer l’arrière-plan d’un bloc de couverture (voir Gutenberg 10.3 et PR #29813

Amélioration de l’interface utilisateur de publication

Depuis WordPress 5.8, l’interface de publication affiche l’icône et le titre du site afin de préciser l’endroit où vous allez publier vos articles ou vos pages (Gutenberg 10.4).

Cette amélioration est bénéfique si vous travaillez en mode plein écran ou sur des appareils mobiles.

Réglages et styles de blocs avec theme.json

Avec WordPress 5.8, le fichier theme.json devient « un point central de configuration », offrant aux développeurs de thèmes un nouveau moyen de personnaliser les réglages et les styles de l’éditeur.

À l’aide d’un fichier theme.json, les thèmes peuvent définir des pré-réglages personnalisés et/ou ajouter la prise en charge de nouvelles fonctionnalités, telles que duotone et les bordures de tableau (voir Réglages et styles globaux).

Selon André Maneiro :

Ce nouveau mécanisme vise à reprendre et à consolider tous les différents appels add_theme_support qui étaient auparavant nécessaires pour contrôler l’éditeur.

Par exemple, vous pouvez définir globalement un préréglage personnalisé de duotone avec le code suivant :

{
	"version": 1,
	"settings": {
		"color": {
			"duotone": [
				{
					"colors": [ "#000", "#0FF" ],
					"slug": "black-cyan",
					"name": "Black Cyan"
				}
			],

Cela écraserait les préréglages par défaut, et vous ne verriez qu’une seule option de duotone :

Ce nouveau mécanisme permet de contrôler les réglages de manière globale ou par bloc. Par exemple, vous pouvez ajouter une taille de police personnalisée de 12px globalement en ajoutant le pré-réglage suivant à votre fichier theme.json :

{
	"version": 1,
	"settings": {
		"typography": {
			"customLineHeight": true,
			"fontSizes": [
				{
					"slug": "extra-extra-small",
					"size": "12px",
					"name": "Extra extra small"
				},
				{...}

Il en résulte une nouvelle taille de police que les utilisateurs peuvent utiliser avec n’importe quel texte dans leur contenu.

Si vous souhaitez uniquement personnaliser le bloc Paragraphe, votre code sera légèrement différent :

{
	"version": 1,
	"settings": {
		"blocks": {
			"core/paragraph": {
				"typography": {
					"fontSizes": [
						{
							"slug": "extra-extra-small",
							"size": "12px",
							"name": "Extra extra small"
						},
						{
							"slug": "extra-small",
							"size": "16px",
							"name": "Extra small"
						},
						{
							"slug": "small",
							"size": "18px",
							"name": "Small"
						},
						{
							"slug": "normal",
							"size": "20px",
							"name": "Normal"
						},
						{
							"slug": "large",
							"size": "24px",
							"name": "Large"
						}
					]
				}
			}
		}
	}
}

Voilà, c’est fait ! Vous venez de définir vos pré-réglages de taille de police personnalisée pour le bloc de paragraphe.

Les blocs du cœur ont été mis à jour pour suivre le nouveau mécanisme, tandis que les blocs tiers peuvent s’adapter au nouveau mécanisme en utilisant le crochet React useSetting (pour en savoir plus sur cette fonction, consultez la dev-note et la documentation API) :

const isEnabled = useSetting( 'spacing.margin' );

Le nouveau mécanisme basé sur le fichier theme.json ne s’applique pas uniquement aux réglages des blocs. En effet, à partir de WordPress 5.8, il ne sera plus nécessaire de créer des styles d’éditeur et de les mettre en file d’attente. Il suffira de déclarer des préréglages à l’intérieur du fichier theme.json ; le moteur générera les classes et les mettra automatiquement en file d’attente à la fois dans l’éditeur et dans l’interface publique.

Le moteur générera également les propriétés personnalisées CSS correspondantes.

Dans l’exemple précédent, nous avons défini cinq pré-réglages fontSizes pour le bloc de paragraphes. Pour ces pré-réglages, les propriétés personnalisées CSS suivantes seront générées :

p {
	--wp--preset--font-size--extra-extra-small: 12px;
	--wp--preset--font-size--extra-small: 16px;
	--wp--preset--font-size--small: 18px;
	--wp--preset--font-size--normal: 20px;
	--wp--preset--font-size--large: 24px;
}

Une fois que vous avez défini la taille de la police du paragraphe dans votre fichier theme.json, l’élément p correspondant prend la classe has-{preset-slug}-{preset-category}.

Cela signifie qu’un paragraphe avec une taille de police extra-extra-small aura la classe has-extra-extra-small-font-size :

<p class="has-extra-extra-small-font-size">Lorem ipsum dolor...</p>

Et voici le bloc de déclaration CSS :

p.has-extra-extra-small-font-size {
	font-size: var(--wp--preset--font-size--extra-extra-small) !important;
}

Pour une vue plus détaillée des réglages et des styles de theme.json, n’oubliez pas de consulter la note de développement et la documentation API.

Consultez également l’appel à tests FSE d’Anne McCarty pour une lecture plus utile et un défi passionnant pour les développeurs qui veulent explorer les nouvelles fonctionnalités de theme.json.

Améliorations de l’API de bloc

Les améliorations de l’API de bloc apportées par WordPress 5.8 méritent une attention particulière de la part des développeurs d’extensions.

L’utilisation du fichier block.json est désormais encouragée comme moyen canonique d’enregistrer les types de blocs et présente plusieurs avantages :

• En ce qui concerne les performances, si le thème prend en charge le chargement différé des ressources, l’enregistrement des types de blocs via le fichier block.json optimisera automatiquement la mise en file d’attente des ressources. En effet, les ressources spécifiées par les propriétés de style et de script seront mises en file d’attente sur l’interface publique uniquement lorsque le bloc sera détecté. Cela permet de développer des extensions plus efficaces, de réduire la taille des pages et d’éviter plusieurs des problèmes abordés dans cet article.
• Le fichier block.json simplifie l’enregistrement des blocs côté serveur en permettant au point de terminaison REST API Types de blocs de lister le bloc.
• Le fichier block.json est également nécessaire si vous décidez d’envoyer votre extension dans le dépôt d’extensions WordPress.

Modifications de la fonction register_block_type

Depuis WordPress 5.8, la fonction register_block_type a été améliorée pour lire les méta-données du fichier block.json. Désormais, le premier paramètre accepte le chemin d’accès au dossier où se trouve le fichier block.json.

Cette fonction peut être utilisée comme indiqué dans l’exemple suivant :

function create_custom_block_init() {
	register_block_type( __DIR__ );
}
add_action( 'init', 'create_custom_block_init' );

Il renvoie le type de bloc enregistré ou false en cas d’échec.

Comme vous pouvez le remarquer, la fonction register_block_type est maintenant utilisée de la même manière que la fonction register_block_type_from_metadata, qui était auparavant la seule fonction disponible pour enregistrer un type de bloc en lisant les méta-données du fichier block.json. Comme expliqué par Greg Ziółkowski :

Nous avons décidé de consolider la fonctionnalité préexistante disponible avec la méthode register_block_type_from_metadata dans register_block_type pour éviter la confusion qu’elle créait. Il est toujours possible d’utiliser les deux fonctions, mais à partir de maintenant nous prévoyons de n’utiliser que la version courte dans les documents et outils officiels.

Une fois le bloc enregistré sur le serveur, il vous suffit d’enregistrer les réglages sur le client en utilisant le même nom de bloc dans votre fichier index.js.

Pour un aperçu plus approfondi des améliorations de l’API de bloc introduites par WordPress 5.8, assurez-vous de consulter la dev-note de Greg Ziółkowski.

Prise en charge de WebP dans WordPress 5.8

Ici, chez Kinsta, nous sommes obsédés par la vitesse des sites et les performances de WordPress. C’est pourquoi la prise en charge du format WebP dans WordPress 5.8 est une nouvelle si excitante pour nous.

Considéré comme un format de nouvelle génération, WebP est un format d’image développé par Google qui offre « une meilleure compression que PNG ou JPEG, ce qui signifie des téléchargements plus rapides et une moindre consommation de données ».

Selon Google :

WebP est un format d’image moderne qui offre une compression supérieure avec et sans perte pour les images sur le web. Grâce à WebP, les webmasters et les développeurs web peuvent créer des images plus légères et plus riches qui rendent le web plus rapide.

Les images WebP sans perte sont 26 % plus petites en taille par rapport aux PNGs. Les images WebP avec perte sont 25 à 34 % plus petites que les images JPEG comparables à un indice de qualité SSIM équivalent.

À partir de WordPress 5.8, vous pourrez utiliser le format d’image WebP de la même manière que les formats JPEG, PNG et GIF. Il vous suffit de téléverser vos images dans votre médiathèque et de les inclure dans votre contenu.

Dans un article précédent, nous avons examiné en profondeur le format WebP et les outils disponibles pour l’utiliser dans WordPress. Maintenant, grâce à la prise en charge des images WebP dans WordPress 5.8, les choses peuvent changer un peu. Comme le format WebP est pris en charge dès le départ, vous n’avez pas besoin d’installer des extensions tierces pour téléverser des images WebP dans WordPress, du moins dans les cas d’utilisation les plus courants.

Notez que, même si vous pouvez désormais téléverser vos images WebP sur WordPress en utilisant la bibliothèque de médias, WordPress ne prend pas en charge la conversion automatique des images au format WebP. Pour activer cette fonctionnalité sur votre site web, vous aurez besoin d’une extension WordPress WebP tierce.

Comment utiliser des images WebP dans WordPress

Vous pouvez convertir vos images en WebP de plusieurs manières différentes :

• Vous pouvez utiliser les utilitaires et la bibliothèque WebP pré-compilés de Google pour Linux, Windows ou Mac OS X.
• Les utilisateurs de Mac peuvent installer un gestionnaire de paquets tel que le paquet Homebrew WebP ou le paquet Macports WebP.
• Vous pouvez utiliser un outil d’édition d’image prenant en charge WebP, comme Squoosh de Google Chrome Labs, le convertisseur d’image par lot XnConvert, un éditeur d’image populaire comme GIMP, et bien d’autres.
• Vous pouvez installer une extension WordPress WebP pour un meilleur contrôle global des images WebP dans WordPress.

Si vous optez pour un outil en ligne de commande, vous pouvez coder et décoder vos images à l’aide des utilitaires cwebp et dwebp. Par exemple, la commande suivante exécute une conversion JPEG vers WebP de base :

cwebp [options] original_image.jpg -o compressed_image.webp

Vous pouvez également effectuer une conversion groupée de vos images en utilisant Bash et cwebp (exemple de Jeremy Wagner) :

find ./ -type f -name '*.png' -exec sh -c 'cwebp -q 75 $1 -o "${1%.png}.webp"' _ {} \;

La commande ci-dessus convertit toutes les images .png au format .webp avec un facteur de compression de 75.

Une fois que vous avez vos images WebP, vous pouvez simplement les téléverser en utilisant la médiathèque de WordPress. Ci-dessous, vous pouvez voir une image JPEG de 127 Ko avant conversion dans la médiathèque :

La taille de l’image WebP compressée est 42 % plus petite que l’image JPEG originale !

Enfin, les images WebP disposent des mêmes fonctions d’édition que les images JPEG, PNG et GIF. Vous pouvez les recadrer, les faire pivoter, les retourner et les mettre à l’échelle, et appliquer les modifications aux tailles d’image de votre choix.

Avertissements à propos de WebP dans WordPress 5.8

Selon Adam Silverstein :

Les images WebP prennent en charge la compression avec ou sans perte, ainsi qu’un format animé et la prise en charge des images transparentes. Dans WordPress, le format WebP sans perte n’est pris en charge que lorsque le serveur d’hébergement utilise Imagick (la bibliothèque PHP) jusqu’à ce que LibGD ajoute un support. En outre, les formats animés et alpha ne sont pas encore pris en charge pour les images redimensionnées (lorsque vous téléversez des images dans ces formats, des images avec perte sont créées à la place).

Si votre hébergeur ne prend pas en charge les images WebP, un message d’erreur s’affichera lorsque vous tenterez de les téléverser. Si vous n’êtes pas sûr que votre hébergeur prenne en charge la bibliothèque Imagick, l’onglet Info de l’outil de santé du site comprend un champ consacré à la bibliothèque Imagick qui fournit cette information.

Avec la prise en charge de WebP, WordPress 5.8 introduit également deux champs supplémentaires dans la section Traitement des médias de Santé du site : la version d’Imagick et les formats de fichiers pris en charge par ImageMagick.

Si le format WebP ne figure pas parmi les types de fichiers pris en charge, vous devrez contacter votre hébergeur pour obtenir de l’aide.

La note de développement fournit des informations supplémentaires sur la prise en charge de WebP dans WordPress 5.8, une FAQ utile et d’autres ressources.

Si l’optimisation des images vous intéresse, vous aimerez peut-être les tutoriels suivants:

• Comment optimiser les images pour le web et les performances
• Pourquoi et comment utiliser la compression avec perte sur vos images WordPress
• Comment utiliser des images WebP sur WordPress (et réduire la taille des fichiers image jusqu’à 35 %)
• 15 meilleurs types de fichiers image
• Tout ce que vous devez savoir sur les tailles d’images de WordPress

Fonctionnalités supplémentaires pour les développeurs

Vous trouverez des dizaines de fonctionnalités intéressantes pour les développeurs dans WordPress 5.8. Dans cet article, nous avons accordé plus d’attention à celles qui devraient avoir l’impact le plus significatif sur votre travail de développement. Mais il existe effectivement de nombreuses nouvelles fonctionnalités qui méritent l’attention, notamment les suivantes:

API de prise en charge de bloc

WordPress 5.8 ajoute de nouveaux indicateurs de prise en charge des blocs permettant aux développeurs de personnaliser les blocs enregistrés avec les dernières fonctionnalités des blocs.

En plus de la prise en charge du bloc expérimental duotone mentionné précédemment (color._experimentalDuotone), WordPress 5.8 ajoute également la prise en charge de la couleur des liens. Pour profiter de cette fonctionnalité, il suffit d’ajouter l’indicateur suivant aux méta-données de votre bloc a:

supports: {
	color: {
		link: true;
	}
}

Vous pouvez définir des valeurs par défaut à l’aide d’attributs, comme le montre l’exemple suivant, ou définir vos pré-réglages dans theme.json :

attributes: {
	style: {
		type: 'object',
		default: {
			color: {
				link: '#FF0000',
			}
		}

Les autres modifications apportées à l’API de bloc sont les suivantes :

• Les prises en charge de fontSize et de lineHeight deviennent stables.
• La prise en charge de spacing a été étendue, et vous pouvez désormais contrôler margin et padding, ainsi que contrôler individuellement les tailles top, right, bottom et left.

Vous pouvez en savoir plus sur l’API de prise en charge des blocs dans WordPress 5.8 dans la dev-note sur les mises à jour de l’API de prise en charge des blocs.

Pour une vue plus détaillée de l’utilisation de l’API de prise en charge de bloc, consultez la documentation officielle de l’API de prise en charge de bloc.

Onglets personnalisés pour la santé du site

Deux nouveaux crochets permettent désormais aux développeurs d’ajouter leurs onglets personnalisés à l’interface Santé du site et de personnaliser les écrans disponibles.

Le filtre site_health_navigation_tabs est un tableau associatif d’ID d’onglets et de libellés permettant d’enregistrer un nouvel onglet dans l’écran Santé du site. Vous pouvez utiliser ce filtre en ajoutant l’exemple de code suivant au fichier de fonctions de votre thème ou dans votre extension personnalisée :

function kinsta_site_health_navigation_tabs( $tabs ) {
	$tabs['kinsta-site-health-tab'] = esc_html_x( 'Kinsta', 'Site Health', 'text-domain' );

	return $tabs;
}
add_filter( 'site_health_navigation_tabs', 'kinsta_site_health_navigation_tabs' );

L’image ci-dessous montre le nouvel onglet Santé du site :

Grâce au filtre site_health_navigation_tabs, il est également possible de réorganiser les onglets ou de supprimer un ou plusieurs éléments.

L’action site_health_tab_content se déclenche lorsqu’un utilisateur se rend sur l’écran Santé du site, à l’exception de l’écran État par défaut. Vous pouvez utiliser ce crochet comme indiqué dans l’extrait suivant (exemple tiré de la dev note) :

function kinsta_site_health_tab_content( $tab ) {
	// Return if this is not your tab.
	if ( 'kinsta-site-health-tab' !== $tab ) {
		return;
	}

	// Include the interface, kept in a separate file just to differentiate code from views.
	include trailingslashit( plugin_dir_path( __FILE__ ) ) . 'views/kinsta-site-health-tab.php';
}
add_action( 'site_health_tab_content', 'kinsta_site_health_tab_content' );

Tout d’abord, elle détecte si l’onglet actuel est votre onglet personnalisé, puis elle charge le contenu de votre écran Santé du site à partir d’un fichier .php. L’action site_health_tab_content permet également aux développeurs d’étendre l’onglet Info par défaut en ajoutant des éléments d’information spécifiques à leurs extensions ou thèmes.

Modification de l’API de l’éditeur de blocs pour prendre en charge plusieurs écrans d’administration

Avec WordPress 5.8, l’éditeur d’articles n’est plus le seul écran d’administration à utiliser l’éditeur de blocs (l’écran des widgets en est un exemple).

Les contributeurs du cœur ont trouvé plusieurs crochets définis sur le serveur dépendant de l’objet $post. Cet objet n’est pas présent dans l’édition du site, les widgets et les écrans de navigation. À l’avenir, plusieurs filtres ont été dépréciés et remplacés par des substitutions tenant compte du contexte.

En outre, une nouvelle classe WP_Block_Editor_Context représentant le contexte actuel de l’éditeur de blocs et diverses méthodes a été introduite.

Ces changements améliorent ces écrans avec de nouvelles capacités et permettront aux développeurs d’ajouter leurs personnalisations.

Pour obtenir une liste complète des modifications apportées à l’API de l’éditeur de blocs en ce qui concerne les écrans d’administration, consultez la note de développement de Greg Ziółkowski.

Fonctionnalités et améliorations supplémentaires

Il y a tellement de nouvelles fonctionnalités et de changements pour les développeurs apportés par WordPress 5.8 qu’il nous serait impossible de les mentionner tous dans cet article. Mais nous avons rassemblé une liste de notes de développement non couvertes ici pour votre lecture supplémentaire :

• Abandon de la prise en charge d’Internet Explorer 11
• Amélioration du chargement des styles de blocs dans WordPress 5.8
• Blocs dans un éditeur iframé (modèle)
• Sur la mise en page et la largeur du contenu dans WordPress 5.8
• Introduction de l’en-tête de plugin « Update URI » dans WordPress 5.8
• Diverses suppressions de l’API de l’éditeur de blocs dans WordPress 5.8
• Changements de l’API REST dans WordPress 5.8
• Diverses modifications destinées aux développeurs dans WordPress 5.8
• Divers ajouts à l’API de l’éditeur de blocs dans WordPress 5.8

Résumé

WordPress 5.8 marque une étape importante sur la voie du Full Site Editing. Mais la deuxième version de WordPress de l’année apporte bien plus que FSE. Les utilisateurs et les développeurs trouveront des tonnes d’améliorations dans l’éditeur de blocs, un nouveau mécanisme theme.json, une API de blocs plus puissante, la prise en charge du format d’image WebP, et bien plus encore.

Nous avons été particulièrement impressionnés par les améliorations, petites et grandes, apportées à l’éditeur de blocs et à son interface utilisateur. Nous apprécions la navigation améliorée entre les blocs, la barre d’outils de bloc remaniée, la clarté enrichie de l’interface et les améliorations apportées à plusieurs blocs.

Ces petits changements améliorent peu à peu l’expérience d’édition et, sans presque s’en rendre compte, on se retrouve à utiliser un logiciel plus performant et plus robuste. C’est WordPress !

C’est à vous maintenant ! Que pensez-vous de Full Site Editing ? Et quels sont vos changements préférés dans WordPress 5.8 ?