Ce guide décrit les principaux changements techniques que vous trouverez sur WordPress 6.2, dont la sortie est prévue le 28 mars 2023.
WordPress 6.2 corrige quelque 300 tickets Trac : 110 sont des améliorations et nouvelles fonctionnalités, 166 sont des corrections de bogues et 20 sont d’autres tâches courantes.
On retrouvera 28 améliorations de performances, 15 améliorations d’accessibilité et 18 améliorations de code notamment dédiées à la prise en charge des versions les plus récentes de PHP.
Du côté du projet Gutenberg, 1645 pull requests ont été fusionnées au cœur de WordPress : 292 améliorations, 354 corrections de bogues et 30 améliorations concernant l’accessibilité de l’éditeur.
Les modifications apportées par WP 6.2 concernent 44 composants du cœur WordPress. Vous trouverez dans cet article des précisions concernant les modifications les plus impactantes.
En route pour un petit tour d’horizon des
nouveautés techniques de WordPress 6.2 🚀
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 vous êtes concerné·e, veuillez lire les notes de développement listées dans cet article consciencieusement afin de vous assurer que votre code fonctionnera avec WordPress 6.2 lorsque cette version sortira le 28 mars 2023.
Les polices Google Font sont maintenant incluses localement dans les thèmes natifs
Suite aux incertitudes juridiques liées à l’utilisation des polices Google Fonts directement chargées depuis les serveurs de Google, les thèmes natifs qui embarquaient auparavant directement des polices provenant des serveurs de Google ne le feront plus à partir de WordPress 6.2.
Cela concerne les thèmes suivants :
- Twenty Twelve à partir de sa version 3.9
- Twenty Thirteen à partir de sa version 3.8
- Twenty Fourteen à partir de sa version 3.6
- Twenty Fifteen à partir de sa version 3.4
- Twenty Sixteen à partir de sa version 2.9
- Twenty Seventeen à partir de sa version 3.2
Les autres thèmes natifs n’utilisent pas directement de polices Google et ne sont donc pas concernés par cette modification.
À partir de maintenant, chaque thème concerné va servir une nouvelle feuille de styles depuis son propre répertoire, au sein du domaine de votre site. Si le thème embarque plusieurs polices différentes, votre thème les embarquera en les plaçant dans une seule feuille de styles pour de meilleures performances.
Voici par exemple la déclaration de feuille de styles de Twenty Thirteen :
<link
rel="stylesheet"
id="twentythirteen-fonts-css"
href="https://example.com/wp-content/themes/twentythirteen/fonts/source-sans-pro-plus-bitter.css?ver=20230328"
media="all"
/>
Comme vous pouvez le voir, les polices sont maintenant directement embarquées depuis les thèmes natifs, afin d’éviter toute dépendance tierce.
Attention : si vous avez déjà modifié ou retiré l’appel Google Fonts via un thème enfant ou via une extension, il est recommandé de vérifier que ce changement n’affecte pas votre site.
Pour en savoir plus, consultez la note de développement suivante :
L’éditeur de blocs
WordPress 6.2 comprend 10 versions du projet Gutenberg – 14.2, 14.3, 14.4, 14.5, 14.6, 14.7, 14.8, 14.9, 15.0 et 15.1. Vous y trouverez de nouvelles API, des mises à niveau de bibliothèques, des améliorations très utiles des Styles globaux, encore plus de fonctionnalités prises en charge nativement par les blocs, de nouveaux crochets d’action et filtres, ainsi que bien d’autres modifications ayant été développées sur ces 10 versions de l’extension Gutenberg.
Pour en savoir plus, consultez les notes de développement suivantes :
Internationalisation
Dans WordPress 6.2, le composant internationalisation (abrégé « i18n ») propose une nouvelle fonction conteneur et propose de faciliter le changement des traductions de l’administration du site pour chaque compte. Voici la note de développement dédiée aux modifications ayant eu lieu sur ce composant :
API de gestion des fichiers système
Si vous utilisiez la fonction copy_dir() pour déplacer des répertoires, vous serez probablement heureux de découvrir la nouvelle fonction move_dir(), qui arrive avec WordPress 6.2.
Notons également l’apparition de la fonction wp_opcache_invalidate() qui sert à vider OPcache pour des fichiers PHP individuels après les avoir surchargés. La fonction wp_opcache_invalidate_directory() a été ajoutée dans le cadre du ticket #57375 afin de vider le cache OPcache de façon récursive pour les fichiers PHP après les avoir surchargés. Cette fonction accepte un paramètre unique $dir, pointant vers le répertoire contenant les fichiers PHP pour lesquels OPcache doit être vidé.
Dans le ticket #57375, la méthode WP_Filesystem_Direct::move() a reçu la possibilité de gérer des répertoires afin de la rendre cohérente par rapport aux méthodes ::move() présentes dans WP_Filesystem_FTPext, WP_Filesystem_ftpsockets et WP_Filesystem_SSH2.
Base de données
La possibilité de nettoyer les noms de tables et de champs a été ajoutée dans la méthode wpdb::prepare(). Plus d’infos dans la note de développement dédiée :
Gestion des publications
La fonction get_page_by_title() est maintenant dépréciée en faveur de l’utilisation de WP_Query.
Performances
WordPress 6.2 apporte plusieurs gains de temps de chargement importants au cœur du CMS. Cela est clairement visualisable dans les tests que nous avons conduits avec des mesures de signaux web essentiels (Web Vitals en anglais) et de chargement côté serveur (Server Timing en anglais).
Les performances des thèmes basés sur des blocs ont également été améliorées, avec un TTFB (en anglais Time to First Byte, ou temps de chargement du premier octet) qui est environ 20 % plus rapide, et aussi 14 % d’amélioration sur le LCP (Largest Contenful Paint, représentant le temps avant que la page complète soit lisible). Sur des pages où vous utilisez de grandes bannières d’images, vous devriez même observer une amélioration du critère LCP d’environ 19 %.
Autres améliorations de performances :
- Le nouveau filtre
pre_wp_load_alloptionspermet de court-circuiter le chargement des options auto-chargées de WordPress avec des conditions personnalisées. Voir le ticket #56045 pour plus d’informations. - Les résultats de la fonction
get_adjacent_post()sont maintenant mis en cache. Voir le ticket #41131. - Les clés de mise en cache de
WP_Term_Querysont dorénavant basées sur du SQL sans variables, afin de pouvoir être mises en cache. Voir le ticket #57298. WP_Queryne parcourt désormais plus les publications deux fois avant de les retourner. Ça peut paraître une évidence, mais le ticket #57373 a nécessité beaucoup de travail sur ce point.- Le chargement différé des métadonnées des termes de taxonomies est à présent plus rapide, grâce à l’utilisation de la fonction
wp_cache_get_multiple(). Voir le ticket #57150. - Les résultats de
wp_get_global_settings()sont maintenant placés en cache au sein d’une seule et unique requête, ce qui améliore de 8 % les temps de réponse du cœur WordPress. Pour en savoir plus, voir le ticket #57502.
Thèmes
Les développeuses et développeurs de thèmes WordPress pourront apprécier l’arrivée de nouvelles fonctionnalités, et devront aussi prendre en compte la suppression de certains fonctionnalités obsolètes :
- La fonctionnalité « Variations de styles » a été ajoutée dans la liste des filtres sur les thèmes sur WordPress.org. Voir le ticket #56869.
- Le fichier
theme.jsonprend maintenant en charge davantage de pseudo-classes CSS liées aux liens hypertextes, comme:linkou:any-link. Voir le ticket #57053. - Les thèmes possédant un nom composé de chiffres sont désormais pris en charge par le CMS via un changement dans
WP_Theme::__construct(). Voir le ticket #54645. - Amélioration des performances des fonctions
_add_block_template_part_area_infoet_add_block_template_infoen diminuant les appels à la fonctionget_option. Voir le ticket #57077. - Une mise en cache a été ajoutée sur
WP_Theme::is_block_theme(). Voir le ticket #57114.
Bibliothèques externes
La bibliothèque jQuery a été mise à jour, elle est passée de la version 3.6.3 à 3.6.4.
En outre, la bibliothèque Requests a aussi été mise à jour. Une note de développement détaille d’ailleurs les changements apportés :
Autres mises à jour
Plusieurs crochets d’action et filtres ont été mis à jour, vous les trouverez dans la note de développement suivante :
Mais ce n’est pas tout !
Voici d’autres composants qui ont reçu des mises à jour notables.
Processus de chargement de WP
Ajout d’une vérification que les fonctions mysqli_connect() ou mysql_connect() sont bien disponibles. Cela résout une erreur fatale potentiellement provoquée par l’absence de l’extension PHP mysqli sur le serveur, et affiche un message d’erreur clair le cas échéant. Voir le ticket #51988.
Commentaires
Ajout de la possibilité de passer le paramètre $comment_ID aux fonctions get_comment_time() et comment_time(). Cela apporte une meilleure cohérence vis-à-vis des fonctions similaires get_comment_date() et comment_date(). Voir le ticket #52322.
Mots de passe d’applications
Les URL en HTTP sont désormais autorisées pour la création de mots de passe d’applications dans le cadre d’un environnement local. Voir le ticket #52617.
Bibliothèques externes
Les bibliothèques suivantes ont été mises à jour :
- jQuery (voir le ticket #57324)
- jQuery Migrate (voir le ticket #56743)
- PHPMailer (voir le ticket #57281)
- element-closest (voir le ticket#52851)
- regenerator runtime (voir le ticket #57646)
- polyfill-library (voir le ticket #57646)
- Requests 2.0 (voir le ticket #54504). Pour en savoir plus sur cette mise à jour, voir la documentation de la bibliothèque Requests 2.0.
Formattage
Optimisation de la fonction de bas niveau wp_kses_bad_protocol() afin d’améliorer les performances de la fonction d’échappement esc_url(). Voir le ticket #22951.
Modernisation du code
Un énorme travail a été fait pour améliorer encore la conformité de la structure du code de WordPress vis-à-vis des versions de PHP supérieures à 8.0. Voir le ticket #56788.
E-mails
L’ajout de pièce jointes avec noms de fichiers personnalisés dans la fonction wp_mail() est maintenant possible en passant un tableau associatif $attachments, où les chaînes utilisées en tant que clés seront employées pour déterminer les noms de fichiers. Voir le ticket #28407.
Médias
Il est maintenant possible de fournir explicitement une valeur booléenne false au paramètre $attr de la fonction wp_get_attachment_image() afin de s’assurer que l’attribut decoding n’est pas ajouté au média. Voir le ticket #57086.
La logique permettant de déterminer les images participant au LCP (Largest Contenful Paint, représentant le temps avant que la page complète soit lisible) au sein des thèmes basés sur des blocs a été grandement améliorée, afin de s’assurer que ces images ne soient pas chargées en différé. Cela permet d’améliorer la conformité LCP des thèmes basés sur des blocs. Cette modification tire par ailleurs profit du principe des éléments de modèles de l’éditeur de site pour éviter de charger en différé les médias situés dans l’entête du site. Un test conduit sur une page créée via un thème basé sur des blocs a permis de souligner une amélioration de 19 % du critère LCP sur WordPress 6.2. Voir les tickets #56930 et #57490 pour plus de détails.
API REST
Ajout de la prise en charge de caractères non latins dans la Regex utilisée pour le point de terminaison template. Ces caractères sont encodés afin de pouvoir être utilisés dans une URL (exemple : %cf%84%ce%b5%cf%83%cf%84). Voir le ticket #57329.
Gestion des comptes
Ajout du nouveau crochet d’action wp_set_password, déclenché après la création d’un mot de passe pour un compte déterminé. Cela aidera les auteur·ices d’extensions à intercepter toutes les utilisations de wp_set_password(), qu’elles proviennent du cœur de WordPress ou d’autres extensions. Voir le ticket #57436.
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 WordPress 6.2 Release Candidate 1. Nous comptons sur vous pour vous assurer 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 de l’anglais puis adapté à partir du Field Guide de WP 6.2 par Jb Audras. Merci à Jenny Dupuy, FX Bénard et Bruno Tritsch pour leur relecture attentive.
