Quoi de neuf dans WordPress 5.5 – Une plongée en profondeur dans une release (épique)

WordPress 5.5 « Eckstine » est sorti, et il est temps pour nous d’introduire les changements et les fonctionnalités les plus remarquables ajoutés au noyau avec la deuxième version WordPress de l’année.

De nos jours, nous sommes habitués à voir de nombreux ajouts à l’éditeur de bloc à chaque sortie de WordPress. WordPress 5.5 ne fait pas exception à la règle !

Cette version apporte également des tonnes de changements non liés à l’éditeur qui devraient avoir un grand impact sur la façon dont nous utilisons le CMS.

Bien que WordPress 5.5 apporte de nombreux changements au noyau de WordPress, plusieurs fonctionnalités attendues avec 5.5 ont été retardées et supprimées de cette version en raison de plusieurs problèmes non résolus. Ainsi, l’édition complète du site, le bloc de navigation, l’écran de navigation et l’écran de widget ne font pas partie de WordPress 5.5.

Si vous souhaitez en savoir plus sur le cycle de développement de WordPress 5.5, consultez les liens ci-dessous :

• 7 juillet 2020 : Bêta 1
• 14 juillet 2020 : Bêta 2
• 21 juillet 2020 : Bêta 3
• 27 juillet 2020 : Bêta 4
• 28 juillet 2020 : RC 1
• 4 août 2020 : RC 2
• 10 August 2020 : RC 3
• 10 août 2020 : Essai pour la sortie de WordPress 5.5
• 11 août 2020 : Date cible pour WordPress 5.5  « Eckstine« 

Alors, quoi de neuf dans WordPress 5.5 ?

Quoi de neuf avec l’éditeur de bloc

Avec la version finale de WordPress 5.5, dix versions de l’extension Gutenberg ont été ajoutées au noyau, apportant un grand nombre d’améliorations pour l’interface utilisateur, de fonctionnalités, de perfectionnements et de corrections de bugs affectant toutes les attentes de l’expérience d’édition, de la convivialité aux fonctionnalités et aux performances.

Il serait presque impossible de mentionner tous ces changements ici, alors dans cet article, vous trouverez juste une sélection de nos nouvelles fonctionnalités et améliorations préférées.

Pour une liste plus complète des améliorations et des fonctionnalités ajoutées à l’éditeur de blocs avec WordPress 5.5, voir les annonces officielles des versions de l’extension : 7.5, 7.6, 7.7, 7.8, 7.9, 8.0, 8.1, 8.2, 8.3, 8.4, 8.5.

Cela étant dit, nous couvrirons ici les ajouts suivants apportés à l’éditeur de bloc avec WordPress 5.5 :

1. 1. Nouveau design de l’UI
   2. Outils de conception de blocs
   3. Modification d’images en ligne
   4. Catégories de blocs et nouveau panneau d’insertion de blocs
   5. Le répertoire de blocs et les extensions de blocs
   6. Modèles de blocs

Nouveau design de l’interface utilisateur

Chaque version de l’extension Gutenberg apporte de petites et de moins petites améliorations qui modifient silencieusement l’expérience globale d’édition. Beaucoup de ces changements vont maintenant être fusionnés dans le noyau de WordPress. Ainsi, lorsque vous lancerez pour la première fois l’éditeur de blocs dans WordPress 5.5, une interface légèrement différente devrait attirer votre attention. Vous trouverez :

• Une barre d’outils de bloc simplifiée
• Un contraste de couleurs plus fort
• De nouvelles icônes
• Des déplaceurs de blocs
• Des éléments environnants
• Des aperçus sur différents écrans
• Une amélioration du glisser-déposer
• Une amélioration et une uniformisation des styles de blocs de focalisation dans l’ensemble de l’interface utilisateur
• La possibilité de formater plusieurs blocs en même temps
• De meilleures performances

Ceux mentionnés ci-dessus ne sont que quelques-uns des nombreux changements qui affectent l’expérience d’édition.

D’autres changements sont également prévus :

Options d’indice et d’exposant

Les options de formatage pour le texte en indice et en exposant sont maintenant disponibles grâce aux contrôles de Rich Text (Gutenberg 8.0).

Sélection de bloc parent

Un tout nouveau bouton de la barre d’outils apparaît désormais lorsque l’on passe le curseur sur le côté gauche de la barre d’outils du bloc. Le nouveau bouton permet de sélectionner les blocs parents dans des contextes imbriqués (Gutenberg 8.3).

Outils de conception de blocs

Plusieurs outils de conception ont été ajoutés à l’extension Gutenberg au cours des derniers mois et vont maintenant être inclus dans le noyau de WordPress 5.5.

Contrôle de la hauteur et dégradés d’arrière-plan

Une première série d’outils permet de contrôler les dimensions et la couleur d’arrière-plan de plusieurs blocs (Gutenberg 7.9).

Contrôles des couleurs de marge intérieure des liens

Deux fonctionnalités supplémentaires sont d’arrivées (Gutenberg 8.3), mais au moment où nous écrivons ces lignes, elles sont encore marquées comme expérimentales :

• Contrôle de marge intérieure pour le bloc de couverture.
• Contrôle de la couleur des liens pour les paragraphes, les titres, les groupes, les colonnes et les blocs de médias et de texte.

Le contrôle de la marge intérieure et de la couleur des liens est désactivé par défaut et les développeurs doivent déclarer explicitement leur prise en charge, comme expliqué dans le manuel de l’éditeur de bloc.

Si vous souhaitez ajouter des contrôles de marge intérieure pour le bloc Couverture à vos thèmes, il suffit d’ajouter la ligne suivante au fichier functions.php de votre thème :

add_theme_support( 'experimental-custom-spacing' );

Si vous souhaitez activer le contrôle de la couleur des liens pour les blocs Paragraphe, Titre, Groupe, Colonnes, et Média & Texte, il suffit d’ajouter la ligne suivante au fichier de fonctions de votre thème :

add_theme_support( 'experimental-link-color' );

Unités et hauteurs de lignes personnalisées

Cette nouvelle fonctionnalité permet de définir les valeurs de hauteur px, em, rem, vw et vh pour le bloc Couverture (Gutenberg 7.9). % est également pris en charge, mais il est omis en raison du rendu imprévisible des hauteurs en pourcentage.

Grâce à la commande de hauteur améliorée, vous pouvez sauter des valeurs par 10 en maintenant la touche Shift enfoncée tout en appuyant sur le up ou le down.

Les développeurs peuvent ajouter le support des unités personnalisées en définissant le drapeau de support custom-units :

add_theme_support( 'custom-units' );

Vous pouvez également définir des unités personnalisées spécifiques :

add_theme_support( 'custom-units', 'rem', 'em' );

Les développeurs peuvent également ajouter des hauteurs de ligne personnalisées pour les titres et les paragraphes en définissant le drapeau de support de hauteur de custom-line-height :

add_theme_support( 'custom-line-height' );

Modification d’images en ligne

Une nouvelle fonction d’édition a été ajoutée à l’éditeur de bloc avec Gutenberg 8.4, permettant aux utilisateurs de modifier les images directement à partir du bloc Image.

Ceci a maintenant été fusionné avec le noyau et, depuis WordPress 5.5, vous pouvez recadrer, faire pivoter, zoomer et ajuster la position des images sans avoir besoin de lancer la médiathèque, ce qui accélère le travail d’édition.

Si vous avez l’habitude de publier des tonnes de photos, vous apprécierez sans doute cette fonction.

Il suffit de cliquer sur le bouton Recadrer dans la barre d’outils d’images et vous aurez accès aux nouvelles fonctionnalités de modification. Lorsque vous êtes satisfait de vos personnalisations, appliquez vos modifications et c’est terminé.

WordPress enregistre une nouvelle image en pièce jointe dans la médiathèque et copie les détails de l’image originale (titre, description, légende, texte alternatif et données EXIF). Cela vous donne un contrôle total sur les nouvelles versions des images.

Catégories de blocs et nouveau panneau d’insertion de blocs

Un panneau d’insertion de blocs redessiné affiche les blocs et les modèles par catégories, ce qui améliore considérablement l’expérience de modification et facilite la recherche de blocs et de modèles (Gutenberg 8.3).

Le répertoire de blocs et les extensions de blocs

Grâce à l’implémentation du répertoire des blocs, vous pouvez trouver, installer et ajouter des blocs tiers directement à partir de l’outil d’insertion de blocs.

Lorsque vous recherchez un bloc, si vous ne l’avez pas déjà installé, une liste d’extensions disponibles dans le répertoire des extensions vous sera demandée. Ces extensions sont appelées « extensions de bloc » et vous pouvez les ajouter à votre éditeur en un seul clic.

Grâce à cette nouvelle fonctionnalité géniale, vous pouvez désormais construire vos propres blocs et les publier dans le répertoire des extensions, mettant ainsi vos créations à la disposition de toute la communauté WordPress.

La bonne nouvelle est que, pour créer vos blocs personnalisés, vous n’avez pas besoin d’être un gourou du PHP. Il vous suffit d’avoir une connaissance pratique de JavaScript.

Vous ne savez pas comment commencer à développer vos propres blocs ? L’incroyable communauté WordPress vous propose un tutoriel simple, étape par étape.

La première version du tutoriel sur les blocs est déjà disponible dans le manuel officiel de l’éditeur de blocs pour vous aider à apprendre les bases du développement de blocs. Vous pouvez en savoir plus sur le répertoire des blocs et le développement d’extensions de blocs sur le blog Make WordPress Plugins.

Modèles de blocs (patterns)

En mars 2020, Gutenberg 7.7 et Gutenberg 7.8 ont introduit les modèles de blocs et l’API de modèles de blocs pour les thèmes et les extensions.

Les modèles de blocs sont des mises en page de blocs prédéfinies permettant aux utilisateurs d’ajouter rapidement des structures complexes de blocs imbriqués à leurs pages. Leur but est d’aider les rédacteurs de contenu et les responsables de sites à surmonter le « syndrome de la page blanche » et à créer facilement des mises en page professionnelles et des vues avancées.

Nous devrions voir les modèles de blocs sous leur meilleur jour avec l’édition globale de site.

Mathias Ventura, architecte en chef du projet Gutenberg, explique clairement à quoi servent les modÈles de blocs :

Une précision – la configuration des « modèles de blocs » concerne moins les parties de modèles (qui sont structurellement significatives) et plus les éléments de conception générale constitués de blocs plus petits. Une fois insérés, ils ne sont pas stockés séparément. Par exemple, une image de « couverture » qui combine quelques blocs pour obtenir un aspect spécifique qui, autrement, demanderait aux utilisateurs un certain travail. Pensez plutôt à une collection de dessins qui peuvent être ajoutés n’importe où sans nécessairement représenter une partie réutilisable d’un modèle de thème.

À la différence des parties de modèles, les blocs sont des éléments de conception qui devraient aider les responsables de sites et les créateurs de contenu à accélérer et à améliorer leur expérience d’édition.

Lancés avec Gutenberg 7.7, les modèlesde blocs sont d’abord apparus dans une extension de colonne latérale. Plus tard, avec la sortie de Gutenberg 8.0, ils sont passés dans un outil d’insertion de blocs remanié qui apparaît maintenant sous la forme d’un panneau placé sur le côté gauche de l’éditeur, comme le montre l’image ci-dessous :

Dans leur phase initiale, les modèles de blocs sont assortis d’un ensemble très limité de modèles. Quoi qu’il en soit, ils apportent une amélioration considérable à l’expérience d’édition et, espérons-le, d’autres seront ajoutés dans un avenir proche.

Comme les blocs réguliers, les modèles peuvent être recherchés et sont organisés dans les catégories suivantes :

• Texte
• Hero
• Colonnes
• Boutons
• Galerie
• Fonctionnalités
• Témoignages
• Non classé

En plus des modèles de blocs intégrés, les développeurs WordPress peuvent fournir à leurs thèmes et extensions des modèles personnalisés en tirant parti d’une toute nouvelle API.

Vous pouvez enregistrer vos modèles personnalisés en utilisant la fonction register_block_pattern et register_block_pattern_category pour les catégories.

register_block_pattern prend deux arguments :

1. Le nom du modèle.
2. Un ensemble de propriétés des modèles.

Les propriétés comprennent les éléments suivants :

• title
• content
• description
• categories
• keywords
• viewportWidth

register_block_pattern_category prend également deux arguments :

1. Le nom de la catégorie du modèle.
2. Un ensemble de propriétés.

L’API fournit également deux fonctions pour désenregistrer les modèles et les catégories : unregister_block_pattern et unregister_block_pattern_category.

La façon dont vous pouvez construire vos propres modèles de blocs est assez simple. Par exemple, copiez et collez le code suivant dans une extension personnalisée ou un fichier de fonctions d’un thème enfant, puis modifiez le nom du modèle selon vos préférences.

add_action( 'init', function(){

	register_block_pattern_category( 
		'kinsta', 
		array( 'label' => __( 'Kinsta stuff', 'kinsta-pattern' ) ) );

	register_block_pattern(
	'kinsta-pattern/my-custom-pattern',
	array(
		'title'			=> __( 'Two Kinsta buttons', 'kinsta-pattern' ),
		'description'	=> _x( 'Two nice buttons.', 'Kinsta Buttons', 'kinsta-pattern' ),
		'content'		=> "<!-- wp:buttons {\"align\":\"center\"} -->\n<div class=\"wp-block-buttons aligncenter\"><!-- wp:button {\"backgroundColor\":\"very-dark-gray\",\"borderRadius\":0} -->\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link has-background has-very-dark-gray-background-color no-border-radius\">" . esc_html__( 'Button One', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button -->\n\n<!-- wp:button {\"textColor\":\"very-dark-gray\",\"borderRadius\":0,\"className\":\"is-style-outline\"} -->\n<div class=\"wp-block-button is-style-outline\"><a class=\"wp-block-button__link has-text-color has-very-dark-gray-color no-border-radius\">" . esc_html__( 'Button Two', 'kinsta-pattern' ) . "</a></div>\n<!-- /wp:button --></div>\n<!-- /wp:buttons -->",
		'categories'	=> array( 'kinsta' ),
	)
	);
});

Le code ci-dessus est une simple personnalisation de l’extrait original de la référence de l’API de bloc. Comme vous pouvez le voir, aucun JavaScript n’est nécessaire.

Voir aussi les modèles de blocs dans WordPress 5.5.

Chargement différé d’images natif dans le noyau de WordPress

Le chargement différé est une technique d’optimisation qui permet de différer le chargement des ressources non critiques. Cela signifie que le navigateur reçoit l’instruction de charger le contenu visible lors du chargement de la page et de différer le téléchargement et le rendu des images placées sous le pli jusqu’à ce qu’elles soient réellement nécessaires.

Avant le chargement différé natif, ou lazy loading, les développeurs web pouvaient charger en différé des ressources via JavaScript, en utilisant l’API IntersectionObserver ou en utilisant les gestionnaires d’événements de scroll, resize et de orientationchange.

Mais depuis que le chargement différé est devenu un standard, nous n’avons plus besoin d’écrire du code personnalisé ou d’utiliser des bibliothèques JavaScript et les images en chargement différé peuvent être implémentées en utilisant le nouvel attribut loading dans les balises img et iframe.

L’attribut de loading détermine si le navigateur doit charger une ressource immédiatement ou attendre que certaines conditions soient remplies. Il prend actuellement en charge les valeurs suivantes :

• lazy : attendre que certaines conditions soient remplies
• eager : charger la ressource immédiatement

Au moment de la rédaction de cet article, le chargement différé natif est pris en charge par Microsoft Edge, Firefox, Google Chrome, le navigateur Opera, le navigateur Android et Chrome pour Android.

Avant WordPress 5.5, le chargement différé n’était possible dans WordPress qu’avec une extension d’optimisation comme Autoptimize, BJ Lazy Load, ou autres. Maintenant, il fait partie du noyau de WordPress et ne nécessite pas l’installation d’extensions supplémentaires !

Chargement différé en natif dans WordPress

Comme l’a rapporté Felix Arntz dans un ancien article sur le blog Make WordPress Core, une implémentation JavaScript de chargement différé dans WordPress a été initialement proposée il y a quelques années, mais elle n’a jamais fait partie du noyau. La nouvelle implémentation du chargement différé d’images en natif élimine tout problème de compatibilité, donc la nouvelle fonctionnalité pourrait être fusionnée en toute sécurité dans le noyau avec WordPress 5.5.

Selon Felix, le chargement différé natif des images WordPress pourraient avoir un un impact bénéfique sur les performances du site et l’expérience utilisateur pour un grand nombre de sites WordPress qui n’utilisent pas d’extensions de chargement différé :

… sans exiger de connaissances techniques ou même de sensibilisation au concept de chargement différé. L’adoption du nouvel attribut de chargement est une grande chance pour WordPress d’ouvrir la voie à un web plus rapide dans son ensemble.

Afin d’éviter les changements de mise en page, loading="lazy" sera automatiquement ajouté aux balises img avec des attributs width et heigh et cela n’est possible que si l’image est disponible pour WordPress en tant que pièce jointe et inclut une classe wp-image-$id.

Le chargement différé est une optimisation indispensable pour toute installation WordPress et tout site web comportant une quantité considérable d’images. Notes de Felix :

Cela permettra d’économiser considérablement la bande passante sur les serveurs et les agents utilisateurs sur les sites où les images situées plus bas dans la page étaient chargées immédiatement, même si l’utilisateur ne les faisait jamais défiler.

Le chargement différé natif dans WordPress fonctionne avec les images suivantes :

• Images dans le contenu d’article (the_content).
• Images dans les extraits d’article (the_excerpt).
• Images dans les widgets texte (widget_text_content).
• Les images des avatars sont rendues via get_avatar().
• Modèles d’images utilisant wp_get_attachment_image

Avec la première implémentation, le chargement différé ne prend en charge que les images, mais on peut s’attendre à une future amélioration du chargement différé sur les balises iframe.

Chargement différé pour les développeurs WordPress

Les développeurs peuvent modifier le comportement par défaut en utilisant plusieurs nouveaux filtres. Parmi ces filtres, wp_lazy_loading_enabled et wp_img_tag_add_loading_attr sont les plus utiles pour les développeurs :

• wp_lazy_loading_enabled active et désactive l’attribut loading. Ce filtre peut être appliqué globalement ou par balise.
• wp_img_tag_add_loading_attr filtre la valeur de l’attribut loading et fournit un moyen de contrôler le chargement différé par image.

L’exemple suivant montre comment désactiver globalement le chargement différé :

add_filter( 'wp_lazy_loading_enabled', '__return_false' );

Nous pouvons également désactiver le chargement différé pour une balise spécifique. Dans l’exemple ci-dessous, le chargement différé est désactivé pour les images dans le contexte the_content (pour en savoir plus, consultez la page Make WordPress Core) :

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

• $default : La valeur booléenne par défaut (true).
• $tag_name : Le nom de l’élément à charger de manière différée.
• contexte $ : Un paramètre optionnel spécifiant le contexte de l’image (voir la liste ci-dessus).

Notez qu’au moment de la rédaction de cet article, le paramètre $tag_name ne supporte que le tag img. Quoi qu’il en soit, comme mentionné ci-dessus, d’autres balises devraient être ajoutées lors de futures implémentations.

Si vous souhaitez un contrôle plus granulaire du chargement différé des images dans WordPress, vous pouvez suivre deux approches différentes selon le contexte.

Si vous travaillez sur le contenu (c’est-à-dire the_content, the_excert, widget_text_content), vous pourriez utiliser le filtre wp_img_tag_add_loading_attr. L’exemple suivant montre comment désactiver le chargement différé sur une image spécifique :

add_filter(
	'wp_img_tag_add_loading_attr',
	function( $value, $image, $context ){
		if ( 'the_content' === $context ){
			$image_url = wp_get_attachment_image_url( 67, 'medium' );
			if ( false !== strpos( $image, ' src="' . $image_url . '"' ) ) {
				return false;
			}
		}
		return $value;
	},
	10,
	3
);

Les développeurs de thèmes peuvent également contrôler les images via wp_get_attachment_image. Dans ce scénario, vous pouvez simplement définir la valeur de l’attribut loading de l’image sur false :

echo wp_get_attachment_image(
	67,
	'medium',
	false,
	array( 'loading' => false ),
);

Native lazy-loading images is coming to #WordPress 5.5, for faster sites and less waste of network resources! And it's accompanied by further image improvements which reduce those annoying layout shifts that make you accidentally click on the wrong things. https://t.co/e7g2s9uSPk

— Felix Arntz (@felixarntz) July 14, 2020

Vous trouverez de plus amples informations sur le chargement différé d’images dans WordPress 5.5 sur le blog Make WordPress Core.

Mises à jour automatiques pour les extensions et les thèmes

L’une des plus grandes préoccupations des propriétaires de sites est la sécurité du site et la mise à jour de votre logiciel est une recommandation commune que chaque propriétaire de site devrait prendre en compte.

Les mises à jour automatiques de WordPress sont disponibles depuis la version 3.7 de WordPress. Maintenant, le problème est que si les mises à jour automatiques sont activées par défaut pour la maintenance de base et les versions de sécurité, avant WordPress 5.5, de nombreux propriétaires de sites ne profitaient pas des mises à jour automatiques pour les extensions et les thèmes.

La raison étant que cette fonctionnalité nécessite des connaissances de base en matière de développement WordPress. En fait, les développeurs pouvaient affiner leurs préférences de mise à jour en définissant une ou plusieurs constantes dans wp-config.php ou en utilisant un filtre dans une extension.

Avec WordPress 5.5, les responsables de site peuvent désormais activer et désactiver les mises à jour automatiques des extensions et des thèmes d’un simple clic, directement dans leur tableau de bord WordPress.

Les mises à jour automatiques des extensions peuvent être activées et désactivées en cliquant sur le lien apparaissant dans la colonne Mises à jour automatiques maintenant disponible dans l’écran des extensions.

Si vous souhaitez activer les mises à jour automatiques pour votre thème, allez sur Apparence > Thèmes, puis survolez votre thème et cliquez sur Détails du thème. Ensuite, cliquez sur le nouveau lien Activer les mises à jour automatiques et vous avez terminé.

La nouvelle interface utilisateur de mise à jour automatique pour les extensions et les thèmes s’accompagne de plusieurs fonctions et hooks disponibles pour les développeurs afin de personnaliser l’expérience de mise à jour automatique.

Fonctions de mise à jour automatique et filtres pour les développeurs d’extensions et de thèmes

Une nouvelle fonction et plusieurs filtres permettent aux développeurs de WordPress de personnaliser de nombreux aspects des mises à jour automatiques des extensions et des thèmes.

UI de la vérification de mise à jour automatique

La nouvelle fonction WordPress wp_is_auto_update_enabled_for_type() vérifie si l’interface utilisateur de la mise à jour automatique est activée pour un type donné. La nouvelle fonction conserve un seul argument ($type) qui détermine le type de mise à jour à vérifier ("theme" ou "plugin") et renvoie true ou false en conséquence.

La nouvelle interface utilisateur de mise à jour automatique peut être désactivée pour les extensions ou les thèmes grâce à deux nouveaux filtres : plugins_auto_update_enabled et themes_auto_update_enabled. Voir l’exemple ci-dessous :

// Disable plugins auto-update UI elements.
add_filter( 'plugins_auto_update_enabled', '__return_false' );

// Disable themes auto-update UI elements.
add_filter( 'themes_auto_update_enabled', '__return_false' );

Les filtres ci-dessus sont documentés dans wp-admin/includes/update.php.

Personnaliser les liens de mise à jour automatique

Les développeurs d’extensions et de thèmes peuvent personnaliser l’affichage HTML des liens de mise à jour automatique.

Le filtre plugin_auto_update_setting_html permet de personnaliser les liens de basculement et le délai entre deux tentatives de mise à jour.

La fonction de rappel conserve les arguments de l’arbre :

• $html : Le HTML du contenu de la colonne de mise à jour automatique de l’extension, y compris les liens d’action de mise à jour automatique et le délai de la prochaine mise à jour.
• $plugin_file : Chemin d’accès au fichier de l’extension relatif au répertoire des extensions.
• $plugin_data : Un tableau de données de l’extension.

Maintenant, si vous souhaitez personnaliser le libellé du texte du lien de mise à jour automatique, vous pouvez utiliser le filtre comme indiqué dans l’extrait suivant.

add_filter( 'plugin_auto_update_setting_html', function( $html, $plugin_file, $plugin_data ){
	if ( 'kinsta-plugin/kinsta-plugin.php' === $plugin_file ) {
		$html = __( 'Custom HTML', 'kinsta-plugin' );
	}
	return $html;	
	}, 
	10, 
	3 
);

L’image ci-dessous montre le résultat à l’écran.

Ce filtre est documenté dans wp-admin/includes/class-wp-plugins-list-table.php.

Sur les sites individuels, vous pouvez personnaliser le modèle JS du lien de mise à jour automatique via le filtre theme_auto_update_setting_template. L’article de blog présentant les mises à jour automatiques des ensions et des thèmes fournit l’exemple suivant pour ce filtre :

function myplugin_auto_update_setting_template( $template ) {
    $text = __( 'Auto-updates are not available for this theme.', 'my-plugin' );
 
    return "<# if ( [ 'my-theme', 'twentytwenty' ].includes( data.id ) ) { #>
        <p>$text</p>
        <# } else { #>
        $template
        <# } #>";
}
add_filter( 'theme_auto_update_setting_template', 'myplugin_auto_update_setting_template' );

Il est recommandé de vérifier le thème cible à l’aide du paramètre data.id.

Si vous travaillez sur une installation multisite de WordPress, vous avez besoin du filtre theme_auto_update_setting_html, qui vous permet de personnaliser les liens des mises à jour automatiques de l’écran des thèmes de la même manière que l’écran des extensions.

Enfin, deux filtres supplémentaires contrôlent toutes les mises à jour automatiques pour chaque thème et extension, y compris les thèmes et extensions qui devraient être installés à l’avenir.

Ces filtres, disponibles depuis WordPress 3.7, remplacent tous les réglages de mise à jour automatique dans votre tableau de bord WordPress. Vous pouvez en savoir plus à ce sujet dans notre rubrique Plongez dans les mises à jour automatiques de WordPress. Pour une vue plus approfondie des mises à jour automatiques pour les extensions et les thèmes, lisez cet article de blog.

Notifications de mise à jour automatique par e-mail et informations sur la santé du site

Depuis WordPress 5.5, une notification par e-mail est envoyée après toute tentative de mise à jour automatique.

Le filtre auto_plugin_theme_update_email hook filtre les e-mails envoyés après une mise à jour automatique en arrière-plan. Voir l’article du blog de dev-notes pour un exemple d’utilisation.

Les notifications automatiques par e-mail peuvent également être désactivées à l’aide de deux nouveaux filtres :

// Disable auto-update email notifications for plugins.
add_filter( 'auto_plugin_update_send_email', '__return_false' );

// Disable auto-update email notifications for themes.
add_filter( 'auto_theme_update_send_email', '__return_false' );

Les informations de mise à jour automatique des extensions et des thèmes sont également affichées dans l’onglet Info de santé du site.

Les développeurs peuvent personnaliser le texte apparaissant sur cet écran en utilisant les filtres plugin_auto_update_debug_string et theme_auto_update_debug_string. Plus d’informations et plusieurs exemples sont disponibles ici.

Plans de sites (sitemap) extensibles dans le noyau

Un plan de site (sitemap) est simplement une liste d’URLs permettant aux moteurs de recherche d’explorer rapidement votre site web.

Les plans de site sont assez similaires à robots.txt, à la différence qu’un fichier robots.txt exclut le contenu de l’indexation, tandis qu’un plan de site fournit une liste d’URLs à indexer par les moteurs de recherche.

Avant WordPress 5.5, les plans de site ne pouvaient être ajoutés aux sites web WordPress qu’à l’aide d’une extension ou d’autres outils.

WordPress 5.5 apporte maintenant une toute nouvelle fonctionnalité de plans de site XML au noyau de WordPress.

Cette nouvelle fonctionnalité ajoute des fonctionnalités de base, mais elle est accompagnée d’un bon nombre de hooks et de filtres permettant aux développeurs d’extensions d’étendre encore les fonctionnalités intégrées.

Les plans de site XML sont activés par défaut (sauf si vous refusez aux moteurs de recherche d’indexer votre site web) et fournissent les types d’objets suivants :

• Page d’accueil
• Page d’articles
• Types de publications de base (pages et articles)
• Types de publications personnalisés
• Taxonomies de base (Étiquettes et catégories)
• Taxonomies personnalisées
• Archives d’auteurs

L’index du plan du site est disponible sur /wp-sitemap.xml, qui contient un maximum de 2 000 URLs. Lorsque la limite maximale est atteinte, un nouveau fichier de plan de site est ajouté.

Comme mentionné précédemment, les développeurs d’extensions peuvent personnaliser leurs plans de site en utilisant une ou plusieurs des nombreuses actions et filtres disponibles. Pour une liste complète des possibilités offertes par les plans de site, voir la documentation de l’extension et l’article de présentation du blog.

Par exemple, vous pouvez désactiver par programmation les plans de site en utilisant le filtre wp_sitemaps_enabled, qui filtre si les plans de site XML sont activés ou non :

add_filter( 'wp_sitemaps_enabled', '__return_false' );

Les plans de site du noyau ne doivent pas entrer en conflit avec les extensions de plan de site que vous avez pu installer sur votre site web. Selon Pascal Birchler sur Make WordPress Core :

La fonction principale des plans de site a été conçue de manière robuste et facilement extensible. Si, pour une raison quelconque, deux sitemaps sont exposés sur un site web (un par le noyau, l’autre par une extension), cela n’a pas de conséquences négatives sur la possibilité de découvrir le site.

Dans le cadre de la fonctionnalité de plan de site XML, une nouvelle fonction esc_xml() permet d’échapper les chaînes de caractères des blocs XML. La fonction et le filtre correspondant sont documentés dans wp-includes/formatting.php.

Au moment où nous écrivons ces lignes, la nouvelle fonction de plan de site ne prend pas en charge les plans de site image/vidéo/nouvelles et cela ne changera probablement pas à l’avenir. Quoi qu’il en soit, de nouveaux filtres et crochets permettant aux développeurs d’ajouter cette fonctionnalité pourraient être ajoutés dans les prochaines versions.

Pour plus d’informations sur les plans de site extensibles, voir l’introduction des développeurs aux plans de site qui couvre les nouvelles classes, fonctions, crochets et filtres.

Transmission des arguments aux fichiers de modèle

Avant WordPress 5.5, le transfert de données vers des fichiers modèles n’était possible que via des variables globales, des variables de requête et quelques autres options non optimales. Maintenant, à partir de WordPress 5.5, un paramètre $args a été ajouté aux fonctions de chargement des modèles (les hooks correspondants ont été mis à jour en conséquence) :

• get_header()
• get_footer()
• get_sidebar()
• get_template_part()
• locate_template()
• load_template()

Les développeurs de thèmes peuvent désormais définir une variable dans un fichier de modèle et la rendre accessible dans n’importe quelle partie de modèle incluse en passant simplement un tableau d’arguments.

Maintenant, alors que cette fonctionnalité ouvre de nouvelles grandes possibilités pour les développeurs de thèmes, Justin Tadlock de WP Tavern pose une bonne question :

Une question demeure : l’arrivée de cette fonctionnalité est-elle trop tardive ? WordPress étant en passe de réorganiser l’ensemble du système de thèmes pour l’intégrer à la prochaine fonction d’édition globale du site, cette fonction ne sera-t-elle utile que pendant les prochains mois ?

Un bon point vient de John Blackbourne :

Même dans un futur où l’édition du site sera globale, il y aura toujours un grand besoin de parties de modèles. Les types de blocs de rendu dynamique peuvent faire et font un bon usage des parties structurées des modèles, par exemple. Ils ne s’excluent pas mutuellement et il y aura toujours des thèmes qui n’utiliseront pas beaucoup les blocs pour la mise en page.

Nous avons finalement contacté Enrico Sorcinelli, contributeur principal de WP, qui nous a fait part de ses réflexions :

Si vous me demandez si nous sommes arrivés trop tard, de mon point de vue, il n’est jamais trop tard !
Je pense qu’à l’avenir les développeurs de thèmes pourront bénéficier de cette opportunité, ce qui n’exclut pas qu’elle puisse être utilisée en symbiose avec l’approche émergente de l’édition globale de site (par exemple pour les blocs avec rendu dynamique).

Il est peut-être tout simplement trop tôt pour dire comment cette fonctionnalité s’associerait exactement à l’édition globale de site, mais une chose semble certaine : les développements futurs offriront de grandes possibilités de créer de meilleurs sites web, tant pour les utilisateurs que pour les développeurs.

Mise à jour d’extensions et de thèmes à partir d’un fichier .zip

Je sais ce que vous pensez : il peut sembler assez « inattendu » de voir cette fonctionnalité apparaître en même temps que les mises à jour automatiques.

Néanmoins, cela a un sens. Avant WordPress 5.5, lorsque la fonction de mise à jour en un clic faisait défaut, les responsables de site ne pouvaient téléverser les mises à jour des extensions/thèmes uniquement via FTP/SFTP ou le gestionnaire de fichiers (apprenez la différence entre FTP et SFTP). Cela était surtout vrai pour les extensions/thèmes personnalisés ou pour les extensions hébergées sur des places de marché tierces.

À partir de WordPress 5.5, vous pouvez mettre à jour les extensions et les thèmes en téléversant un fichier .zip depuis votre ordinateur dans votre tableau de bord WordPress.

Si vous souhaitez mettre à jour une extension, allez sur l’écran Extension > Ajouter et cliquez sur le bouton Téléverser une extension. Ensuite, si l’extension est installée sur votre site web, un nouvel écran vous indique que « Cette extension est déjà installé e » et affiche la version actuelle et les détails de la version téléversée.

Le processus est assez similaire pour les mises à jour des thèmes.

Naviguez jusqu’à l’écran Apparence > Thèmes, puis cliquez sur Ajouter, puis sur Téléverser un thème. Si le thème est déjà installé sur votre site WordPress, un nouvel écran vous informe que « Ce thème est déjà installé » et affiche la version actuelle et les détails de la version téléversée.

Améliorations supplémentaires pour les développeurs avec WordPress 5.5

En plus de ce que nous avons couvert jusqu’à présent, quelques ajouts méritent l’attention d’un développeur.

Nouvelle fonction wp_get_environment_type()

Une nouvelle fonction wp_get_environment_type() permet de détecter le type d’environnement actuel d’un site web, ce qui permet aux développeurs d’adapter les fonctionnalités des extensions et des thèmes à l’environnement actuel.

Par défaut, wp_get_environment_type() retourne production. Les autres valeurs supportées sont le development et la staging. Quoi qu’il en soit, les développeurs sont autorisés à définir des types d’environnement supplémentaires si nécessaire.

Il existe trois méthodes pour définir un type d’environnement de site web. Vous pouvez utiliser un ordre de priorité :

• La variable d’environnement PHP WP_ENVIRONMENT_TYPE 
• La constante WP_ENVIRONMENT_TYPE.
• Le filtre wp_get_environment_type.

Par exemple, si vous souhaitez définir votre environnement en staging, vous pouvez définir la constante WP_ENVIRONMENT_TYPE dans votre fichier wp-config.php comme indiqué ci-dessous :

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

Si le type d’environnement est en develoment, WP_DEBUG sera automatiquement mis sur true même si vous ne l’avez pas défini explicitement.

Changements de l’API REST dans WordPress 5.5

WordPress 5.5 apporte également de nombreux changements à l’API REST. Nous verrons plusieurs nouveaux points de terminaison (endpoints), de nouveaux paramètres et des modifications du schéma JSON, de nouvelles fonctions et d’autres améliorations.

Voici une liste rapide des nouveaux points de terminaison :

Types de blocs

Un nouveau point de terminaison permet d’obtenir tous les types de blocs enregistrés :

• GET /wp/v2/block-types renverra tous les types de blocs enregistrés.
• GET /wp/v2/block-types/core renverra tous les blocs avec le nom core.
• GET /wp/v2/block-types/core/quote renvoie la définition du bloc de quote.

Extensions

Un nouveau point de terminaison permet de gérer les extensions :

• GET /wp/v2/plugins renvoie une liste de toutes les extensions installées.
• GET /wp/v2/plugins/plugin-name/plugin-name renvoie des informations sur l’extension spécifiée.
• POST /wp/v2/plugins { slug : "plugin-name" } installe l’extension spécifiée depuis le répertoire des extensions
• PUT /wp/v2/plugins/plugin-name/plugin-name { status : "active" } active l’extension spécifiée
• DELETE /wp/v2/plugins/plugin-name/plugin-name supprime une extension inactive.

Modification d’images

Un nouveau point de terminaison permet de faire des recherches dans le répertoire des blocs :

• GET /wp/v2/block-directory/search?term=block-name recherche bloc-name dans le répertoire de bloc.

Image Editing

Associé à la nouvelle fonction de modification d’images en ligne, un nouveau point de terminaison permet de modifier les pièces jointes des images dans la médiathèque :

POST /wp/v2/media/5/edit modifie l’image avec l’ID 5

Voir les notes de développement du noyau de WordPress pour un aperçu plus détaillé de tous les changements apportés à l’API REST avec WordPress 5.5.

Résumé

Nous sommes ravis de toutes ces nouvelles fonctionnalités et améliorations que WordPress 5.5 apporte en une seule version.

Cela montre l’énorme quantité de travail qui se fait dans les coulisses et nous apprécions profondément tous les efforts et l’engagement de chaque contributeur principal.

Si les changements énumérés ci-dessus ne vous suffisent pas, voici d’autres améliorations venant avec WordPress 5.5 :

• 65 nouvelles icônes ajoutées à la police d’icônes Dashicons dans le noyau de WordPress
• Améliorations de l’accessibilité des listes de liens dans les widgets
• Nouveaux styles CSS pour les boutons désactivés
• Invalidation du cache d’opcode
• Meilleur contrôle de redirect_guess_404_permalink()
• Améliorations liées au PHP
• Modifications de la base de code
• Modifications des fonctions et du filtre du logo personnalisé
• Bloquer les mises à jour de l’API
• Filtres des titres de pages d’archives
• Ajout d’icônes dans Twenty Twenty
• Et bien d’autres encore

N’oubliez pas de participer à notre webinaire gratuit entièrement consacré à WordPress 5.5 !

Maintenant, c’est votre tour. Quelles sont les fonctionnalités et/ou améliorations que vous appréciez le plus dans WordPress 5.5 ? Et quelles sont les fonctionnalités que vous aimeriez voir ajoutées à WordPress 5.6 ? Faites-nous part de vos réflexions dans la section des commentaires ci-dessous !