Quoi de neuf dans WordPress 5.7 (chargement différé, HTTPS, mises à jour de l’UI, nouvelles API, et bien plus encore)

Nous avons l’habitude de voir des changements mineurs et d’autres plus ou moins mineurs, ainsi que de nouvelles fonctionnalités ajoutées au cœur de WordPress à chaque nouvelle version. WordPress 5.7 ne fait pas exception à la règle, et il est bon de voir comment chaque nouvelle version nous rapproche un peu plus de la vue d’ensemble.

Avec plusieurs versions de l’éditeur de blocs fusionnées dans le cœur, la nouvelle version améliore l’expérience globale d’édition et permet aux développeurs de construire des blocs plus avancés et d’ajouter des personnalisations plus puissantes à l’éditeur de blocs.

En plus de l’éditeur, WordPress 5.7 introduit également des tonnes de changements et de fonctionnalités intéressantes, notamment des iframes à chargement différé (lazy loading), des mises à jour de l’interface de connexion et d’inscription, des liens de réinitialisation des mots de passe, un grand nombre de corrections de bogues, et bien plus encore.

Nous avons effectué nos tests sur DevKinsta, et nous sommes prêts à partager avec vous nos fonctionnalités favorites et les changements qui sont apportés à WordPress 5.7 – avec, bien sûr, des tonnes de captures d’écran et de codes.

Si vous voulez vous plonger plus profondément dans la première grande version de 2021, consultez le cycle de développement de WordPress 5.7, le Planning Roundup et le Field Guide.

Donc, pendant que nous continuons à attendre l’édition complète du site (dans WordPress 5.8), mettons-nous à l’aise et profitons des nouveautés de WordPress 5.7 !

Quoi de neuf dans l’éditeur de bloc

WordPress 5.7 apporte de nombreuses versions de l’extension Gutenberg au cœur. Il serait impossible de mentionner ici tous ces ajouts en plus des nombreuses modifications et corrections de bogues apportées à l’éditeur, mais vous pouvez vous rendre sur les liens suivants pour plonger dans chaque version : 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 9.9.

Les corrections de bogues et les améliorations de performance de Gutenberg 10.0 et 10.1 font également partie de WordPress 5.7.

Ceci dit, passons en revue notre liste des fonctionnalités et des changements les plus intéressants ajoutés à l’éditeur de blocs avec WordPress 5.7 :

Fonctionnalités, améliorations et API des variations de bloc

Introduites avec WordPress 5.4, les variations de blocs permettent à l’utilisateur de sélectionner une instance différente du même bloc.

Cette fonctionnalité fonctionne en tandem avec l’API de variations de bloc, un outil puissant qui permet aux développeurs d’ajouter, de gérer ou de supprimer des variations de blocs.

WordPress 5.7 introduit plusieurs améliorations, fonctionnalités et nouvelles API pour les variations de blocs, offrant une meilleure interface utilisateur et des outils plus puissants pour les développeurs. Plongeons dans le vif du sujet.

Transformations des variations de bloc

Introduit pour la première fois avec Gutenberg 9.4 et maintenant ajouté à WordPress 5.7, un commutateur de transformation pour variation apparaît sous la carte de bloc pour les blocs supportant cette fonction.

Lors de l’enregistrement d’une nouvelle variation de bloc, les développeurs de blocs peuvent ajouter le commutateur de variation à l’inspecteur de bloc en ajoutant la nouvelle option transform pour la variation de bloc au champ scope, comme le montre l’exemple suivant (code JS uniquement) :

wp.blocks.registerBlockVariation( 'core/heading', { 
	name: 'green-text', 
	title: 'Green Text', 
	description: 'This block has green text. It overrides the default description.',  
	attributes: { 
		content: 'Green Text', 
		textColor: 'vivid-green-cyan' 
	}, 
	icon: 'palmtree', 
	scope: [ 'inserter', 'transform' ] 
} );

Dans cet exemple, une variation de bloc apparaît dans deux zones de l’interface utilisateur de l’éditeur, l’outil d’insertion de bloc et l’inspecteur de bloc.

Pour un aperçu approfondi des transformations de variation de bloc, voir également PR #26687.

Les informations sur les blocs correspondent maintenant aux variations des blocs

Depuis WordPress 5.7 (et Gutenberg 9.7), l’interface utilisateur affiche des informations plus spécifiques sur les variations de blocs, alors qu’auparavant elle ne présentait que des informations génériques.

Les blocs intégrés et les icônes sociales sont construits comme des variations de blocs ; ils fournissent de bons exemples de WordPress faisant correspondre des informations de blocs avec des variations de blocs.

Ces changements affectent l’inspecteur de bloc, le bloc de barre de navigation et les fils d’Ariane. Depuis Gutenberg 9.8, cette amélioration de l’UI s’applique également au commutateur de bloc.

Nouvelles API de variations de blocs

WordPress 5.7 introduit également de nouvelles API que les développeurs peuvent utiliser lors de l’enregistrement des variations de blocs pour afficher les informations correctes d’une variation de bloc (Gutenberg 9.7).

La nouvelle propriété isActive est une fonction qui accepte les attributs d’un bloc. Vous pouvez utiliser les attributs de la variation pour déterminer si une variation est active (voir aussi la référence API de bloc).

Les développeurs de blocs peuvent utiliser cette fonction pour afficher des informations sur les variations au lieu des informations sur les blocs. Un exemple pourrait être le bloc embed, où nous pouvons modifier la valeur de l’attribut providerNameSlug (un exemple tiré de la note de dev) :

const variations = [
{
	name: 'wordpress',
	title: 'WordPress',
	keywords: [ __( 'post' ), __( 'blog' ) ],
	description: __( 'Embed a WordPress post.' ),
	attributes: { providerNameSlug: 'wordpress' },
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.providerNameSlug === variationAttributes.providerNameSlug,
},
];

Dans l’exemple suivant, la propriété isActive est utilisée pour modifier l’attribut de couleur :

variations: [
{
	name: 'blue',
	title: __( 'Blue Quote' ),
	isDefault: true,
	attributes: { color: 'blue', className: 'is-style-blue-quote' },
	icon: 'format-quote',
	isActive: ( blockAttributes, variationAttributes ) =>
		blockAttributes.color === variationAttributes.color
},
],

Le nouveau hook useBlockDisplayInformation renvoie des informations sur un bloc donné. Le nouveau hook prend en compte la propriété isActive d’une variation de bloc et renvoie title, icon et description du bloc.

Ces changements concernent le bloc carte (outils de l’inspecteur), la navigation en vue liste (barre supérieure) et les fils d’Ariane (voir aussi PR #27469).

Nouvelles fonctionnalités de bloc de boutons

Quelques nouvelles caractéristiques améliorent la fonctionnalité et l’interface du bloc de boutons.

Dimensions des boutons

Un nouveau contrôle disponible dans la colonne latérale des réglages nous permet désormais de définir un pourcentage de largeur pour les boutons logés dans les blocs de boutons (Gutenberg 9.4).

Il suffit de sélectionner un bouton et de choisir 25 %, 50 %, 75 % ou 100 %. Les pourcentages se réfèrent au conteneur parent. L’image ci-dessous montre différentes combinaisons de dimensions de boutons.

Pour plus d’informations techniques, consultez les PR #25999 et #26781.

Mise en page verticale

Cette nouvelle fonctionnalité ajoute des variations pour l’orientation verticale du bloc de boutons. Les utilisateurs peuvent passer d’une mise en page horizontale à une disposition verticale en utilisant le commutateur Transformations disponible dans le panneau des réglages du bloc (Gutenberg 9.6).

Améliorations des icônes sociales

WordPress 5.7 ajoute de nouvelles options de personnalisation aux icônes sociales : prise en charge de la taille et des couleurs personnalisées.

Taille des icônes sociales

Le bloc d’icônes sociales étant sélectionné, la barre d’outils du bloc propose désormais un menu d’options de taille avec les tailles disponibles (Gutenberg 9.4).

Couleurs personnalisées dans les icônes sociales

Le même bloc prend désormais en charge les réglages de couleur, ce qui nous permet de définir différentes couleurs personnalisées pour les icônes et les arrière-plans (Gutenberg 9.9).

Vous pouvez maintenant utiliser la palette de couleurs du thème pour les icônes sociales, ce qui permet d’éviter que les couleurs des icônes ne correspondent pas à celles de votre site web (voir aussi PR #28084).

Prise en charge de taille de police

WordPress 5.7 ajoute la prise en charge de la taille des polices pour les blocs Liste et Code.

Taille de police dans le bloc Liste

Une carte de typographie avec des contrôles pour la taille des polices a été ajoutée aux réglages du bloc Liste (Gutenberg 9.4).

Les utilisateurs peuvent choisir l’une des tailles de police disponibles pour les éléments de la liste ou définir une taille de police personnalisée exprimée en pixels. Le bouton « Réinitialiser » rétablit les valeurs par défaut.

Prise en charge de la taille de police dans le bloc Code

WordPress 5.7 prend également en charge la gestion de la taille des polices dans les blocs Code. Lorsqu’un bloc code est sélectionné, la colonne latérale des réglages du bloc affiche un nouveau contrôle de la taille de la police. Ce contrôle vous permet soit de choisir l’une des tailles prédéfinies disponibles dans votre thème, soit de définir une valeur personnalisée en pixels (Gutenberg 9.5).

L’implémentation de cette fonctionnalité permet également d’utiliser des variables de style globales dans le CSS des blocs de code (voir aussi PR #27294). L’image ci-dessous montre un bloc de code sur l’interface publique avec le thème Twenty Twenty installé.

Alignement sur toute la hauteur dans le bloc Couverture

WordPress 5.7 introduit un nouveau composant d’alignement de la barre d’outils en pleine hauteur. Il a d’abord été ajouté à l’éditeur de blocs avec Gutenberg 9.5. Maintenant, il est fusionné dans le cœur et implémenté dans le bloc Couverture.

Si vous activez le bouton de la barre d’outils de bloc, en gardant un œil sur le contrôle de la hauteur minimale, vous verrez que l’alignement sur toute la hauteur n’est qu’une abréviation pour 100vh (pour en savoir plus sur les longueurs en pourcentage de vue).

Vous pouvez utiliser l’alignement en hauteur en combinaison avec d’autres réglages de contrôle comme l’arrière-plan fixe, la position du contenu, etc. Vous serez probablement surpris par le nombre d’effets impressionnants que vous pourrez créer sur vos pages.

Blocs et compostions en glisser-déposer depuis l’outil d’insertion

L’outil d’insertion de blocs supporte désormais le glisser-déposer pour les blocs et les compositions. Les utilisateurs peuvent saisir n’importe quel bloc ou composition depuis l’outil d’insertion et les placer n’importe où sur le canevas de l’article (Gutenberg 9.6 et 9.7).

Notez que le glisser-déposer ne fonctionne que si votre thème prend en charge les compositions de blocs.

Bloc d’espace semi-transparent

Au lieu de l’ancienne couleur gris opaque, le bloc Espace a maintenant un arrière-plan semi-transparent (Gutenberg 9.8).

Cette fonction devrait permettre d’identifier plus facilement le bloc Espace qui se trouve au-dessus de toute couleur d’arrière-plan.

Améliorations supplémentaires dans l’éditeur de bloc méritant d’être mentionnées

Notre liste ne couvre pas toutes les fonctionnalités et améliorations fusionnées dans le cœur, alors assurez-vous de consulter la documentation officielle et les notes de développement pour un registre plus complet des nouveautés dans l’éditeur de blocs avec WordPress 5.7.

Mais pour n’en citer que quelques-unes, vous trouverez également dans 5.7 :

• Activation automatique du mode sombre lorsque l’arrière-plan sombre est activé (PR #28233)
• Icônes Patreon, Telegram et Tiktok ajoutées aux icônes sociales (PR #26118)
• Toutes les unités prises en charge dans les réglages de taille de police (PR #26475)
• Aperçu des transformations de bloc (PR #27861)
• Amélioration de l’aperçu de composition de bloc dans l’insertion de bloc (PR #27204)
• La modale Options a été améliorée, et le nom a été changé en Préférences
• Changements dans l’API @wordpress/data
• Modifications de l’API des blocs internes
• Améliorations des fonctions d’importation/exportation
• Modifications des composants et des blocs de l’éditeur de bloc

Chargement différé des iframes

Le chargement différé est une technique d’optimisation qui reporte le chargement des ressources non critiques jusqu’à ce qu’elles soient dans la fenêtre de l’utilisateur. Les images et les ressources intégrées qui sont en chargement différé ne sont pas téléchargées et rendues avant d’être nécessaires. Cette technique peut améliorer considérablement les performances d’un site, notamment pour les sites web contenant des images et des vidéos en haute définition.

Avant le chargement différé natif, les développeurs ne pouvaient faire un chargement différé des ressources que via JavaScript. Les utilisateurs de WordPress étaient obligés d’utiliser une extension pour obtenir le même effet. Depuis que le chargement différé est devenu un standard, les images et les iframes peuvent être chargées de manière différée en ajoutant simplement l’attribut loading="lazy" aux balises img et iframe.

WordPress 5.5 a introduit le chargement différé d’image en natif dans le cœur de WordPress, en ajoutant automatiquement l’attribut loading="lazy" aux balises img avec les attributs width et height spécifiés.

Maintenant, depuis WordPress 5.7, le chargement différé est étendu aux balises iframe. Comme pour les images, afin d’éviter les changements de mise en page, loading="lazy" ne sera ajouté qu’aux balises iframe dont les attributs width et height sont spécifiés.

Dans WordPress, le chargement différé natif fonctionne avec les iframes dans les contextes suivants :

• iframes dans le contenu d’article (the_content)
• iframes dans les extraits d’article (the_excerpt)
• iframes dans les widgets texte (widget_text_content)

Dans WordPress, la majorité des iframes reposent sur l’intégration oEmbed, qui transforme automatiquement une URL en balise iframe correspondante. Malheureusement, tous les services web ne fournissent pas les attributs width et height pour les iframes ; cela empêche WordPress d’ajouter l’attribut loading à ces iframes.

L’image ci-dessous montre une balise iframe avec l’attribut loading="lazy" :

Selon Felix Arntz :

Le marquage de ces balises iframe est contrôlé par le service web respectif, et seuls certains de ces services web suivent la meilleure pratique consistant à fournir des attributs width et height. Comme WordPress ne peut pas deviner les dimensions de la ressource intégrée, l’attribut loading="lazy" ne sera ajouté que si la balise oEmbed iframe est fournie avec les deux attributs de dimension présents.

L’image suivante montre une balise iframe sans l’attribut loading="lazy" :

Des iframes à chargement différé pour les développeurs

Du point de vue d’un développeur, la nouvelle fonctionnalité a nécessité plusieurs changements, notamment :

• Le comportement de la fonction wp_filter_content_tags() a été étendu pour ajouter l’attribut loading aux balises iframe. Auparavant, l’attribut loading n’était ajouté qu’aux balises img.
• Par défaut, la fonction wp_lazy_loading_enabled() renvoie désormais true pour les balises iframe (lorsqu’elles sont activées).
• La nouvelle fonction wp_iframe_tag_add_loading_attr() permet d’ajouter l’attribut loading aux balises iframe (similaire à wp_img_tag_add_loading_attr() voir la référence du code).
• Le filtre wp_iframe_tag_add_loading_attr permet de personnaliser le chargement différé sur des iframes spécifiques. Le renvoi de false ou d’une chaîne vide n’ajoutera pas l’attribut.

Vous pouvez remplacer le comportement par défaut en utilisant le filtre existant wp_lazy_loading_enabled, qui renvoie maintenant true pour les balises iframe.

add_filter(
	'wp_lazy_loading_enabled',
	function( $default, $tag_name, $context ){
		if ( 'iframe' === $tag_name && 'the_content' === $context ){
			return false;
		}
		return $default;
	},
	10,
	3
);

Vous pouvez également utiliser le nouveau filtre wp_iframe_tag_add_loading_attr, qui permet de personnaliser le comportement d’une balise iframe spécifique. Par exemple, vous pouvez désactiver le chargement différé pour les vidéos YouTube dans un contexte particulier.

Le code ci-dessous est basé sur un exemple tiré de la note de développement et montre comment désactiver le chargement différé pour les iframes intégrant des vidéos YouTube :

add_filter(
	'wp_iframe_tag_add_loading_attr',
	function( $value, $iframe, $context ){
		if ( 'the_content' === $context && false !== strpos( $iframe, 'youtube.com' ) {
		return false;
	},
	10,
	3
);

Notez que tous les navigateurs web ne supportent généralement pas le chargement différé au moment de la rédaction de cet article. Vous pouvez voir ci-dessous que Firefox et Safari ne prennent en charge que le chargement différé sur les images.

Migration d’un site de HTTP à HTTPS en un clic

Depuis la version 5.7, WordPress détecte si l’environnement d’un site web prend en charge le HTTPS. Si c’est le cas, la section État HTTPS de l’outil de Santé du site fournit un bouton d’appel à l’action permettant aux administrateurs de sites de basculer leurs sites web de HTTP en HTTPS en un seul clic. Le contenu du site est migré à la volée, ce qui nous évite d’avoir à faire face à des avertissements de contenu mixte.

WordPress affichera une notification si le HTTPS n’est pas supporté.

Migration de HTTP vers le HTTPS pour les développeurs

En plus de la nouvelle fonction automatique accessible depuis l’outil Santé du site, WordPress 5.7 introduit de nouvelles fonctions permettant aux développeurs de tester et de personnaliser différents aspects de la détection et de la migration HTTPS.

La nouvelle fonction wp_is_using_https() renvoie true si « Adresse du site » ((home_url())et « Adresse WordPress » (site_url()) ont toutes deux une URL contenant https. Cette nouvelle fonctionnalité est clairement illustrée par Felix Arntz dans la note de développement :

Essentiellement, le fait de changer ces deux URL en HTTPS indique formellement que le site utilise le HTTPS. Bien qu’il existe d’autres moyens d’activer partiellement le HTTPS dans WordPress (par exemple avec la constante FORCE_SSL_ADMIN), le nouveau mécanisme de détection se concentre sur l’utilisation du HTTPS sur l’ensemble du site, c’est-à-dire son interface publique et son administration.

Alors que la fonction wp_is_using_https() vérifie la présence de https dans l’URL, wp_is_https_supported() vérifie si l’environnement du site supporte correctement le HTTPS.

Cette fonction vérifie essentiellement la présence de l’option https_detection_errors dans la base de données et renvoie true si aucune erreur n’est détectée. Au cas où votre environnement ne prendrait pas en charge le HTTPS, l’option https_detection_errors sera présente dans le tableau wp_options, comme le montre l’image suivante :

Comme mentionné ci-dessus, les URL codées en dur dans le contenu du site sont modifiées à la volée, tout cela grâce à deux nouvelles fonctions : wp_replace_insecure_home_url() et wp_should_replace_insecure_home_url().

Pour migrer un site web de HTTP à HTTPS, il suffirait à l’administrateur du site de mettre à jour manuellement « Adresse du site » et « Adresse WordPress » pour inclure HTTPS au lieu de HTTP. Toutefois, pour faciliter encore plus les choses, WordPress 5.7 introduit la nouvelle fonction wp_update_urls_to_https().

Cette dernière fonction permet la migration d’un site et de tout son contenu de HTTP à HTTPS en un seul clic (du moins dans les scénarios les plus courants, comme lorsque l’adresse du site correspond à l’adresse WordPress). C’est une nouveauté absolue et une amélioration considérable de l’expérience d’administration de WordPress.

Pour des aspects plus techniques de la détection et de la migration HTTPS, voir la note de développement de Felix Arntz, ainsi que les tickets #47577 et #51437.

Nouvelles fonctions liées à Post Parent

WordPress 5.7 introduit deux nouvelles fonctions liées à la fonction Post Parent. Elles sont simples à utiliser et vous aident à réduire la logique des extensions et des thèmes.

has_parent_post()

La fonction has_parent_post() est une balise conditionnelle qui vérifie si un article donné a un parent, puis renvoie true ou false en conséquence. Elle accepte l’ID d’article ou l’objet WP_Post comme paramètre, et utilise la variable globale $post si elle est disponible. Voir l’exemple suivant :

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	// your code here
<?php endif; ?>

get_parent_post()

La fonction get_parent_post() est une balise de modèle qui récupère l’objet parent WP_Post pour un article donné. Comme la fonction précédente, elle accepte l’ID d’article ou l’objet WP_Post comme paramètre. Voir l’exemple d’utilisation suivant :

<a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>"><?php echo get_the_title( get_parent_post( get_the_ID() ) ); ?></a>

Dans le monde réel, nous utiliserions ces fonctions en conjonction. Vous pouvez effectuer un test par vous-même en ajoutant le code suivant de la note de dev au fichier de modèle single.php de votre thème :

<?php if ( has_parent_post( get_the_ID() ) ) : ?>
	<p><a href="<?php the_permalink( get_parent_post( get_the_ID() ) ); ?>">
	<?php
		echo sprintf(
			esc_html__( 'Parent page: %s', 'text-domain' ),
			get_the_title( get_parent_post( get_the_ID() ) )
		);
	?>
	</a></p>
<?php endif; ?>

Mises à jour de l’interface de connexion et d’inscription

WordPress 5.7 apporte plusieurs améliorations à la fonction de connexion et d’inscription, avec une interface améliorée de réinitialisation du mot de passe, de nouveaux crochets et d’autres changements mineurs.

Écran de réinitialisation du mot de passe

L’écran Réinitialiser le mot de passe comporte désormais deux boutons : Générer le mot de passe et Enregistrer le mot de passe. Le premier bouton génère un nouveau mot de passe fort à chaque clic, tandis que le second bouton enregistre votre mot de passe. Ce changement devrait permettre d’améliorer l’expérience de réinitialisation des mots de passe pour les nouveaux utilisateurs de WordPress.

L’image ci-dessous compare les écrans de réinitialisation du mot de passe dans WordPress 5.6 et 5.7 :

Nouveaux filtres

Le nouveau crochet lostpassword_user_data nous permet de filtrer la variable $user_data lors de la réinitialisation du mot de passe. Les développeurs peuvent désormais procéder à la validation de l’utilisateur en utilisant des données personnalisées au lieu d’un identifiant ou d’une adresse e-mail. Pour un exemple concret, consultez ce commentaire de Marcelo Villela Gusmão.

Le nouveau crochet de filtre login_site_html_link nous permet de remplacer complètement le HTML générant le lien « Retour vers {site_name} » par un code/lien personnalisé. Les développeurs peuvent désormais définir un texte personnalisé pour le lien, ainsi que modifier le lien lui-même. Vous pouvez utiliser le filtre comme illustré dans l’exemple suivant :

function custom_login_site_html_link( $link ) {
	return '<a href="' . esc_url( home_url( '/blog/' ) ) . '">' . __( 'Back to my awesome blog', 'textdomain' ) . '</a>';
}
add_filter( 'login_site_html_link', 'custom_login_site_html_link', 10, 1 );

L’image ci-dessous montre l’affichage sur l’écran :

Pour d’autres changements, consultez les modifications des écrans de connexion et d’enregistrement dans WordPress 5.7 dev.

Nouvelles fonctions permettant de vérifier si un article est visible publiquement

WordPress 5.7 introduit deux nouvelles fonctions permettant aux développeurs de vérifier si un article est visible par le public.

is_post_status_viewable()

La nouvelle fonction is_post_status_viewable() permet aux développeurs de déterminer si un article est visible par le public en fonction de son post status.

Cette nouvelle fonction offre un meilleur moyen de vérifier si un article est visible que la fonction is_post_type_viewable() existante, qui peut vérifier si un type de publication est visible pour les utilisateurs anonymes mais n’aide pas à déterminer si un article spécifique est visible ou non.

Pour les types de publications intégrés, is_post_status_viewable() vérifie l’attribut public. Pour les types de publication personnalisés, elle vérifie plutôt l’attribut public_queryable.

Nous avons testé le code suivant, basé sur l’exemple de la note de développement, dans une installation locale :

$current_post_status = get_post_status( $post );
if ( is_post_status_viewable( $current_post_status ) ) {
	echo '<p>This post uses a public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
} else {
	echo '<p>This post uses a non public post status.' . ' Current status: <strong>' . $current_post_status . '</strong></p>';
}

is_post_status_viewable() accepte un paramètre nécessaire :

• $post_status (string|stdClass) Le nom ou l’objet de l’état de l’article.

Dans un article de blog public, le code ci-dessus produirait le résultat suivant :

Dans un article privé, le résultat serait le suivant :

Jean-Baptiste Audras, l’auteur de la note de développement, met en garde :

Veuillez noter que les articles protégés par un mot de passe sont considérés comme étant accessibles au public, alors que les articles privés ne le sont pas.

is_post_publicly_viewable()

La nouvelle fonction is_post_publicly_viewable() renvoie true si les deux fonctions is_post_status_viewable() et is_post_type_viewable() renvoient true. Elle nous permet également de déterminer si un article spécifique est visible par le public (c’est-à-dire s’il est visible pour les utilisateurs non connectés).

is_post_publicly_viewable() accepte un paramètre optionnel :

• $post (string|stdClass) Un ID ou un objet d’article. Par défaut, l’objet global $post est passé.

Un nouveau crochet dynamique pour filtrer le contenu d’un type de bloc spécifique

WordPress 5.7 introduit un nouveau crochet dynamique qui permet aux développeurs de filtrer le contenu d’un type de bloc spécifique.

Ce nouveau filtre render_block_{$this->name} est similaire au filtre render_block existant, avec une différence essentielle : render_block filtre le contenu d’un seul bloc, tandis que le nouveau crochet dynamique filtre le contenu du type de bloc {$this->name}.

Pour utiliser ce filtre, vous devez fournir les paramètres suivants :

• $block_content (chaîne de caractères) : Le contenu du bloc à ajouter.
• $bloc (tableau) : Le bloc complet, y compris le nom et les attributs.

Le callback renvoie le contenu du bloc modifié.

L’exemple suivant montre une utilisation de ce filtre sur un bloc de paragraphes :

add_filter( 
	'render_block_core/paragraph', 
	function( $block_content, $block ) {
		$content  = '<div class="my-custom-wrapper">' . $block_content . '</div>';
		return $content;
	}, 
	10, 
	2 
);

Dans cet exemple, le suffixe core/paragraph est le slug du type de bloc paragraphe du cœur. Pour les blocs personnalisés, le slug doit être quelque chose comme my-custom-plugin/my-custom-block.

Voir la note de développement pour un aperçu plus approfondi et des exemples d’utilisation supplémentaires.

Nouvelle API robots

La balise méta robots permet aux propriétaires de sites de contrôler comment une page web doit être indexée et servie aux utilisateurs dans les résultats des moteurs de recherche (entre-temps, n’oubliez pas de consulter notre guide sur le SEO).

WordPress 5.7 introduit une nouvelle API Robots permettant aux développeurs de contrôler cette balise méta robots. La nouvelle API fournit un filtre wp_robots permettant aux développeurs de thèmes d’ajouter leurs directives personnalisées à la balise méta robots.

En outre, la directive max-image-preview:large est désormais ajoutée par défaut aux sites web configurés pour être visibles par les moteurs de recherche. Elle indique aux moteurs de recherche d’afficher des aperçus d’images de grande taille dans les résultats de recherche.

Les développeurs peuvent supprimer la directive max-image-preview:large en utilisant le code suivant :

remove_filter( 'wp_robots', 'wp_robots_max_image_preview_large' );

La personnalisation des directives robots est assez simple. L’exemple suivant, tiré de la note de développement, montre comment ajouter une directive personnalisée à la balise méta :

add_filter( 
	'wp_robots', 
	function( $robots ) {
		$robots['follow'] = true;
		return $robots;
	}
);

Le code ci-dessus produirait le résultat suivant :

<meta name="robots" content="max-image-preview:large, follow">

Il est également possible de supprimer des directives existantes en supprimant simplement des valeurs. Le code suivant désactive la directive max-image-preview :

function my_wp_robots_directives( $robots ) {
	unset( $robots['max-image-preview'] );
	$robots['follow'] = true;
	return $robots;
}
add_filter( 'wp_robots', 'my_wp_robots_directives' );

Vous trouverez un aperçu détaillé de la balise méta robots sur le blog Ahrefs et la référence Google Search. Voir la note de développement pour plus d’informations sur la nouvelle API WordPress Robots et les fonctions obsolètes.

Liens de réinitialisation du mot de passe

Une nouvelle fonctionnalité permet désormais aux administrateurs du site d’envoyer des liens de réinitialisation du mot de passe par e-mail à tout utilisateur enregistré. Cette fonction peut être utile si un utilisateur ne peut pas accéder au lien de réinitialisation du mot de passe pour une raison quelconque.

Les administrateurs du site peuvent envoyer un lien de réinitialisation du mot de passe par e-mail à partir de différentes zones. Tout d’abord, vous trouverez une nouvelle section proposant un bouton « Envoyer le lien de réinitialisation » dans l’écran du profil de l’utilisateur.

Si tout se passe bien, vous devriez voir une notification confirmant que le lien de réinitialisation du mot de passe a été envoyé par e-mail à l’utilisateur.

Vous pouvez également envoyer un lien de réinitialisation du mot de passe à partir de l’écran des comptes.

Vous pouvez même sélectionner plusieurs comptes et envoyer des liens de réinitialisation de mot de passe de manière groupée.

Comme mentionné précédemment, les utilisateurs recevront un e-mail contenant un lien de réinitialisation du mot de passe. L’image suivante montre un e-mail de réinitialisation de mot de passe dans l’outil DevKinsta Email Inbox.

Les développeurs peuvent utiliser les filtres retrieve_password_title et retrieve_password_message pour personnaliser l’objet et le message de l’e-mail.

Améliorations supplémentaires pour les développeurs

Nouvelles fonctions pour passer des attributs aux balises script

Plusieurs nouvelles fonctions permettent désormais de passer des attributs aux balises <script> (c’est-à-dire async ou nonce).

wp_get_script_tag()

wp_get_script_tag() charge une balise script formatée et injecte automatiquement l’attribut type si le thème n’a pas déclaré le support des balises script HTML5. Il accepte un tableau de paires clé-valeur représentant les attributs ajoutés à la balise <script>.

Cette fonction est associée au nouveau filtre wp_script_attributes, qui peut être utilisé pour filtrer les attributs.

wp_print_script_tag()

wp_print_script_tag() affiche une balise de script formatée.

wp_get_inline_script_tag()

wp_get_inline_script_tag() enveloppe le JavaScript en ligne dans une balise script.

Cette fonction a un crochet wp_inline_script_attributes correspondant qui filtre les attributs à ajouter à une balise script.

wp_print_inline_script_tag()

wp_print_inline_script_tag() affiche du JavaScript en ligne dans une balise script.

wp_sanitize_script_attributes()

La nouvelle fonction wp_sanitize_script_attributes() est utilisée pour sanitiser un tableau d’attributs en une chaîne d’attributs. Ils peuvent ensuite être ajoutés à une balise script.

Consultez la note de développement pour obtenir des informations supplémentaires et des exemples d’utilisation.

Couleurs WP-Admin standardisées

Dans le cadre d’un projet plus vaste visant à nettoyer le CSS WP-Admin, WordPress utilise désormais une nouvelle palette de couleurs WP-Admin standardisée. La nouvelle palette de couleurs comprend 12 nuances de bleus, verts, rouges et jaunes. Elle ajoute également 13 nuances de gris, de noirs et de blancs. De plus, elle répond aux exigences minimales du rapport de contraste recommandé par le WCAG 2.0 recommended contrast ratio.

Selon Jean-Baptiste Audras :

La normalisation de cet ensemble de couleurs aidera les contributeurs à prendre des décisions de conception cohérentes et accessibles. Les développeurs de thèmes et d’extensions sont encouragés à utiliser cette nouvelle palette de couleurs, pour une meilleure cohérence entre leurs produits et le cœur de WordPress.

Constante WP_MEMORY_LIMIT dans la santé du site

La constante WP_MEMORY_LIMIT indique la quantité maximale de mémoire que PHP peut consommer.

La constante WP_MEMORY_LIMIT a été ajoutée à l’onglet Info de Santé du site, ce qui n’était pas le cas dans les versions précédentes de WordPress.

Des modifications supplémentaires pour les développeurs sont énumérées dans diverses modifications axées sur les développeurs et changements de l’API REST dans WordPress 5.7. Vous trouverez une liste complète des notes de développement dans le guide de WordPress 5.7.

Résumé

La part de marché de WordPress continue d’augmenter à un rythme soutenu :

WordPress est utilisé par 64,4 % des sites web dont nous connaissons le système de gestion de contenu. Cela représente 40,3 % de tous les sites web.

C’est une preuve significative de la santé du CMS, en particulier pour ceux qui construisent leur entreprise sur WordPress. Et c’est aussi une excellente raison de prêter attention à ce qui se passe dans l’écosystème WordPress.

WordPress 5.7 ajoute des tonnes de nouvelles fonctionnalités et d’améliorations pour les utilisateurs et les développeurs, mais ce n’est qu’un aperçu de ce que nous pouvons attendre en 2021.

C’est à vous de jouer maintenant. Avons-nous manqué quelque chose d’important ? Quelles sont vos modifications et fonctionnalités préférées dans WordPress 5.7 ?