Ce guide décrit les principaux changements techniques que vous trouverez sur WordPress 6.4, dont la sortie est prévue le 7 novembre 2023.
L’équipe de direction de WordPress 6.4 et les contributrices et contributeurs du projet qui ont travaillé sur cette version souhaitent mettre en valeur à travers ce guide les avancées majeures proposées, parmi les 284 tickets traités, dont 113 correspondent à des améliorations et nouvelles fonctionnalités, tandis que 134 tickets sont des corrections de bugs, auxquels s’ajoutent 21 tâches diverses.
Cette version implémente par ailleurs 64 tickets ayant un focus sur les performances et 17 sur l’accessibilité, tandis que 33 tickets sont liés à la modernisation du code du CMS.
Le projet Gutenberg inclut quant à lui plus de 1400 pull requests, dont 420 correspondent à des améliorations, 445 à des correctifs de bugs et 42 à des améliorations de l’accessibilité.
Les modifications de WordPress 6.4 se répartissent dans 45 composants Core, et vous trouverez dans ce communiqué les modifications les plus impactantes, composant par composant.
En route pour un petit tour d’horizon des
nouveautés techniques de WordPress 6.4 🚀
Tous les liens de cet article pointent vers des notes de développement rédigées en anglais.
L’objectif est de fournir un panorama général des changements techniques apportés par cette version, en français, puis de diriger les personnes qui souhaitent en savoir plus vers les notes de développement en anglais.
À noter : certaines modifications listées ici vont nécessiter des actions de la part des auteurs et autrices de thèmes et d’extensions, qui devront adapter ou modifier leur code. Si cela vous concerne, veuillez lire consciencieusement les notes de développement listées dans cet article afin de vous assurer que votre code fonctionnera avec WordPress 6.4 lorsque cette version sortira le 7 novembre 2023.
Changements sur l’éditeur de blocs
WordPress 6.4 implémente 6 versions de l’extension Gutenberg : 16.2, 16.3, 16.4, 16.5, 16.6, et 16.7. Vous trouverez une nouvelle API Block Hooks pour filtrer vos blocs, la possibilité de déclarer vos propres catégories de médias, des modifications sur le paquet @wordpress/components, des mises à jour des composants d’interface et de nombreuses autres modifications.
L’API Block Hooks (#53987) est un mécanisme d’extensibilité pour les thèmes basés sur des blocs. C’est une première étape pour apporter aux thèmes basés sur des blocs le concept bien connu de crochets (en anglais hooks) qui permet d’étendre les fonctionnalités des thèmes classiques avec des filtres et des actions.
Un nombre important de modifications ont été apportées au paquet @wordpress/components :
Il y a également beaucoup d’autres modifications de l’éditeur, comme une nouvelle prise en charge des images d’arrière-plan pour les blocs, la typographie fluide, la possibilité de désactiver globalement ou spécifiquement les options de mise en page des blocs à l’aide du fichier theme.json, une API stabilisée pour les Innerblocks, et bien plus encore :
Notifications sur l’administration
Deux nouvelles fonctions permettent une abstraction de la génération du balisage HTML afin de simplifier la maintenance, d’encourager une plus grande cohérence et de permettre d’activer le passage de paramètres et le fitrage des messages sur toutes les notifications employées sur l’interface d’administration de WordPress.
Ces fonctions sont destinées au cœur du CMS lui-même mais leur utilisation est aussi recommandée aux personnes qui développent des extensions :
Général
Une note de développement sera bientôt publiée afin de détailler une nouvelle fonction wp_trigger_error() qui vient en complément de la fonction préexistante _doing_it_wrong() (voir le ticket #57686).
API HTML
WordPress 6.4 poursuit le développement de l’API HTML en introduisant un premier processeur HTML minimaliste comprenant le concept de fil d’Ariane, et rend par exemple possible de rechercher des images étant enfants directs de élément div donné.
6.4 ajoute également plusieurs fonctionnalités liées à CSS et aux classes dans le processeur de balises, ce qui rend possible de rechercher une balise contenant plus d’un nom de classe, ou de rechercher une balise ne contenant pas un nom de classe spécifié.
Médias
Les nouvelles installations WordPress n’auront désormais plus de page de fichier attaché par défaut, la fonctionnalité étant maintenant désactivée complètement pour tous les nouveaux sites. Cela bénéficiera au référencement des sites en évitant de faire perdre du temps aux moteurs d’indexations qui doivent indexer ces pages par défaut alors que ces pages ne sont souvent pas pertinentes pour les personnes visitant votre site.
Cette modification introduit une nouvelle option wp_attachment_pages_enabled permettant de contrôler le comportement des pages de fichiers attachés pour les sites existants :
Améliorations des performances
Une grande partie des travaux sur WordPress 6.4 a tourné autour des améliorations de performances et d’efficience du CMS, et en particulier sur la gestion du cache objet :
Les nouvelles fonctions get_options(), wp_prime_option_caches(), et wp_set_option_autoload_values() permettent de mettre en place des solutions plus performantes lorsque l’on récupère des options stockées en base de données :
Le chargement des fichiers modèles a également été amélioré :
Chargement des images
Plusieurs améliorations ont été faites sur la fonction wp_get_loading_optimization_attributes(), qui fournit un lieu unique pour gérer l’optimisation des attributs de gestion du chargement, tout spécialement concernant les images et les iframes.
Chargement des scripts
À partir de WordPress 6.4, des stratégies de chargement des scripts seront employées pour les scripts chargés par le cœur du CMS ou par les thèmes natifs de WordPress sur l’interface publique (en anglais front-end) de vos sites. La plupart du temps, la stratégie de chargement defer est utilisée puisqu’elle est la plus cohérente dans son comportement de chargement à partir du moment où l’attribut defer s’exécute toujours une fois que le DOM est chargé. Un script utilisant l’attribut async pourrait de son côté bloquer le rendu du script s’il est déjà mis en cache. Par ailleurs, le chargement à l’aide de defer a été déplacé du pied du document en direction de la partie <head> afin que les ressources concernées soient identifiées le plus tôt possible lors du chargement de la page, et que la stratégie de chargement soit appliquée le plus tôt possible.
Chargement des feuilles de styles
La note de développement suivante détaille les modifications faites sur le chargement des feuilles de styles. Le focus principal porte sur le remplacement des balises style affichées via l’action wp_head avec des appels à la fonction wp_add_inline_style() :
Autres améliorations concernant les performances
- Des gains significatifs ont été obtenus en introduisant une gestion du cache objet dans la nouvelle méthode
WP_Theme::get_block_patterns(). - Des vérifications non indispensables ont été retirées sur l’API
Themes. Ces vérifications portaient sur la correspondance entre le répertoire de la feuille de styles du thème courant et le répertoire des fichiers modèles. - Une nouvelle méthode
WP_Theme::get_block_template_folders()améliore quand à elle les performances de la fonctionget_block_theme_folders()et la gestion des erreurs. La vérification des modèles de blocs au sein des thèmes est ainsi plus rapide. - Taxonomies : une double sanitisation de la fonction
get_terma été retirée. Ce changement retire des appels inutiles àsanitize_term, ce qui améliore les performances de la fonction (ticket #58329). - Thèmes : les constantes
TEMPLATEPATHetSTYLESHEETPATHon été dépréciées. Les fonctionsget_template_directory()etget_stylesheet_directory()doivent maintenant être utilisées à la place (ticket #18298).
Globalement, WordPress 6.4 présente de meilleures performances et les développeur·euses apprécieront la réduction de la charge pesant sur les processus d’entrée/sortie.
Autres changements techniques
Comptes
WordPress 6.4 apporte plusieurs améliorations importantes au balisage HTML de la page wp-login.php pour rendre sa structure plus optimale et pour faciliter la mise en forme de cette page pour les personnes qui souhaitent la personnaliser (ticket #30685).
Clarification des liens « Add New » pour une meilleure accessibilité de l’administration
À partir de WordPress 6.4, les valeurs par défaut du libellé add_new utilisé dans les types de publications personnalisés ont été modifiées afin d’y intégrer le nom du type de publication. Cela apporte une correspondance avec le libellé add_new_item et fournit un meilleur contexte ce qui améliore l’accessibilité des boutons et liens présents dans l’interface d’administration (ticket #47125).
Si vous utilisiez auparavant la déclaration suivante : 'add_new' => _x( 'Add New', 'Book', 'my-plugin' )
alors nous vous encourageons à la remplacer par :'add_new' => __( 'Add New Book', 'my-plugin' )
Modifications des prérequis pour les tests d’intégration
PHPUnit Polyfills version 1.1.0 est requis pour faire tourner des tests d’intégration sur WordPress 6.4 (ticket #59510).
API HTTP
Les classes, méthodes et filtres de WP_Http_Curl et WP_Http_Streams ont été dépréciés car ces classes ne sont plus utilisées dans le cœur de WordPress depuis l’implémentation de la bibliothèque Request (ticket #58705).
Révisions
Les révisions sont maintenant utilisables sur les champs personnalisés des publications (ticket #20564) :
Que vous développiez des thèmes ou des extensions, pensez à tester et retester votre code pour vous assurer de sa compatibilité avec ces changements. Vous pouvez utiliser l’extension Beta Tester sur un site de test pour vérifier la compatibilité de vos développements avec la version de test WordPress 6.4 Release Candidate 2. Nous comptons sur vous pour vérifier que votre code fonctionne correctement avec le cœur du CMS, pour le bien des millions d’utilisateurs et utilisatrices de WordPress ♥️
Ce guide a été traduit et réadapté à partir du Field Guide de WP 6.4 par Jb Audras.
Laisser un commentaire
Vous devez vous connecter pour publier un commentaire.