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 fonction get_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_term a é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 TEMPLATEPATH et STYLESHEETPATH on été dépréciées. Les fonctions get_template_directory() et get_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.

Ce guide décrit les principaux changements techniques que vous trouverez sur WordPress 6.3, dont la sortie est prévue le 8 août 2023.

Cette version implémente 345 tickets : 126 tickets correspondent à des améliorations et nouvelles fonctionnalités, tandis que 198 tickets sont des corrections de bugs, auxquels s’ajoutent 21 tâches diverses.

Cette version implémente par ailleurs 68 tickets ayant un focus sur les performances et 23 sur l’accessibilité, tandis que 33 tickets sont liés à la modernisation du code du CMS.

Le projet Gutenberg inclut quant à lui 1737 pull requests, dont 307 correspondent à des améliorations, 481 à des correctifs de bugs et 55 à des améliorations d’accessibilité.

Les modifications de WordPress 6.3 se répartissent dans 43 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.3 🚀

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.3 lorsque cette version sortira le 8 août 2023.

L’éditeur de blocs

WordPress 6.3 n’implémente pas moins de 10 versions de l’extension Gutenberg : 15.2, 15.3, 15.4, 15.5, 15.6, 15.7, 15.8, 15.9, 16.0 et 16.1. Vous trouverez de nouvelles API, de nouvelles propriétés de blocs, un mode d’édition de blocs, des classes de couleurs et de nombreuses autres modifications.

À noter : les blocs réutilisables ont été renommés en « compositions synchronisées ».

Pour en savoir plus, consultez les notes de développement suivantes :

Thèmes natifs

Les thèmes natifs ont abandonné le support du navigateur Internet Explorer et n’incluent donc plus aucun script ou feuille de styles destinée à ce navigateur. Les scripts HTML5 Shiv ne sont d’ailleurs plus chargés non plus dans les thèmes Twenty Thirteen, Twenty Fifteen et Twenty Seventeen (ticket #56699).

Les personnes qui souhaitent continuer à supporter IE peuvent cependant utiliser un bout de code pour restaurer ces fonctionnalités.

API de gestion du cache

L’API de gestion du cache a reçu de nombreuses améliorations, notamment l’introduction de nouveaux groupes de cache spécifiques aux requêtes afin d’offrir un meilleur contrôle aux développeur·euses.

Vous pouvez maintenant définir le moment d’expiration du cache d’un groupe, vider le cache de groupes spécifiques, modifier la dernière valeur d’un groupe ou encore déclarer certains groupes d’objets mis en cache comme n’étant pas persistants. Avec ces changements, vous pouvez implémenter votre propre stratégie personnalisée d’invalidation du cache.

API de gestion du système de fichiers

Les fichiers masqués (préfixés par .) peuvent maintenant être inclus dans la fonction list_files() avec un nouveau paramètre optionnel $include_hidden. Sa valeur par défaut est false pour cause de rétrocompatibilité (ticket #53659).

Mode développement

Une nouvelle constante WP_DEVELOPMENT_MODE a été introduite afin de déterminer un contexte de développement spécifique. Les valeurs reconnues pour cette constante sont core, plugin, theme, all, ou une chaîne vide, valeur par défaut indiquant que le site n’est pas dans un contexte de développement.

Deux nouvelles fonctions ont été ajoutées pour interagir avec le mode développement : wp_in_development_mode( $mode ) et wp_get_development_mode().

Les différents contextes de développement affectent des fonctionnalités de mise en cache spécifiques. Par exemple, le cache est surchargé lorsque le site se situe en mode développement de thème, mais pas si l’on est en mode développement core (ticket #57487).

La valeur actuelle de la constante WP_DEVELOPMENT_MODE est aussi accessible sur l’écran Outils > Santé du site > Informations, dans la section listant les constantes WordPress (#58646).

Prise en charge de PHP

La prise en charge de PHP 5 a été abandonnée dans WordPress 6.3.

La nouvelle version minimale prise en charge est PHP 7.0.

La version recommandée de PHP demeure toujours 7.4 ou plus (ticket #57345).

Internationalisation

Plusieurs améliorations, dont la possibilité de court-circuiter le filtre load_textdomain et de réduire le temps de chargement des traductions en temps réel.

Médias

Le composant Médias a reçu plusieurs améliorations destinées à diminuer le temps de chargement des contenus comprenant des images. WordPress ajoute maintenant automatiquement l’attribut fetchpriority avec la valeur high à l’image qui est la plus susceptible d’être considérée comme l’image « LCP » (Largest Contentful Paint).

D’autres améliorations ont été faites sur la gestion automatique du chargement différé des images afin de mieux détecter les moments où l’attribut doit être omis, sur certaines images.

API de gestion des métadonnées

Les performances de la gestion des métadonnées ont été grandement améliorées en développant la capacité de WordPress a charger de façon conditionnelle certaines métadonnées des termes de taxonomies, des commentaires ou encore des sites d’un multisite. Ce chargement conditionnel permet d’éviter de demander la récupération de données alors qu’elles ne sont pas utilisées dans l’écran. Cela réduit les requêtes inutiles en base de données et améliore les performances d’ensemble de votre site.

Gestion des publications

La fonction get_pages() a été refactorisée afin d’utiliser WP_Query. Cette amélioration réduit significativement la complexité de la fonction historique get_pages() en déchargeant la responsabilité des performances et de la gestion du cache sur la classe WP_Query (tickets #55806 et #12821).

Chargement des scripts

La prise en charge des attributs HTML5 async et defer a été ajoutée, ce qui permet aux développeur·euses de définir une stratégie de chargement de leurs scripts. La stratégie de chargement peut être activée en modifiant le paramètre $in_footer pour lui fournir un tableau contenant une stratégie de chargement pour les fonctions wp_register_script() et wp_enqueue_script(). Si elle est présente, la stratégie de chargement sera ajoutée à la balise script associée.

Gestion des mises à jour des extensions et des thèmes

WordPress 6.3 propose une nouvelle fonctionnalité de restauration. Cela permettra à WordPress de restaurer automatiquement la version précédente d’un thème ou d’une extension si la mise à jour automatique associée a fait planter le site.

• Lorsqu’un thème ou une extension est mise à jour, la version précédente est déplacée dans un répertoire de sauvegarde temporaire :
  • wp-content/upgrade-temp-backup/plugins/[slug] pour les extensions ;
  • wp-content/upgrade-temp-backup/themes/[slug] pour les thèmes.
• Si la mise à jour échoue, alors la sauvegarde est restaurée dans son emplacement d’origine.
• Si la mise à jour réussit, la sauvegarde temporaire est supprimée.

Deux nouveaux tests sont également ajoutés à l’écran de Santé du site :

• Vérification que le répertoire upgrade-temp-backup est accessible en écriture ;
• Vérification qu’il y a assez d’espace disque disponible pour effectuer les mises à jour sans risque.

Veuillez noter que cette fonctionnalité de restauration ne peut pas être utilisée pour remettre en place la version précédente d’un thème ou d’une extension après une mise à jour réussie. Cela ne fonctionne que si le site a rencontré une erreur fatale et que le site est donc considéré comme étant non fonctionnel.

Gestion des comptes

La classe WP_User_Query était la dernière classe de ce type qui ne permettait pas encore la mise en cache des résultats, c’est maintenant chose faite. Chaque appels à la classe WP_User_Query sera maintenant automatiquement mis en cache par défaut, à moins qu’un paramètre n’indique de ne pas le faire. Il est aussi possible de désactiver la mise en cache globalement en utilisant un filtre.

Les résultats des requêtes sont placés dans le groupe de cache user-queries. La mise en cache est désactivée pour les requêtes utilisant le paramètre field et pour les requêtes comprenant plus de 3 champs.

Autres changements techniques

API CRON

La limite de la mémoire CRON a été agrandie sur la constante WP_MAX_MEMORY_LIMIT (par défaut de 256 Mo). Un nouveau filtre cron_memory_limit a été ajouté pour ajuster cette valeur si nécessaire (ticket #56628).

Éditeur

Un nouvel attribut source a été ajouté sur les compositions de blocs afin de permettre de les filtrer à partir de cette source (ticket #58622).

Contenus embarqués

• Anghami a été ajouté en tant que fournisseur oEmbed de confiance (ticket #49850) ;
• La prise en charge des profils de créateur·ice TikTok a été ajoutée (ticket #55784).

Formatage

• Ajout des attributs ARIA suivants aux attributs autorisés dans les fonctions KSES : aria-controls, aria-expanded, and aria-current (ticket #55370) ;
• La fonction CSS repeat() a été ajoutée aux éléments autorisés dans les fonctions KSES (ticket #58551).

Divers

• Dans les fonctions KSES, la fonction safecss_filter_attr() a été revue afin d’autoriser la propriété filter à recevoir une URL en référence à un élément SVG (ticket #57780) ;
• strpos() a été remplacé par différentes fonctions PHP modernes afin de faire évoluer le code du CMS (tickets #58012, #58206 et #58220) ;
• Dans la classe WP_Comments_List_Table, lorsque la fonction get_comments() est appelée, le paramètre update_comment_post_cache est passé avec la valeur true, afin d’améliorer les performances (#57802) ;
• La fonction _wp_array_get() est la fonction la plus appelée sur l’interface publique de tous les sites WordPress, puisqu’elle est appelée environ 23 000 fois sur chaque chargement de page sur un thème basé sur des blocs. WordPress 6.3 ajoute quelques améliorations de performances sur cette fonction (ticket #58376) ;
• Un nouveau crochet d’action bulk_edit_posts a été ajouté afin de permettre de déclencher une action après que les données d’une édition par lot aient été traitées et avant de renvoyer les résultats. Cela permet notamment aux développeurs et développeuses d’ajouter d’autres modifications sans avoir besoin de greffer des appels AJAX supplémentaires (ticket #28112).

API REST

• L’API REST Themes permet maintenant de savoir si un thème prend en charge l’éditeur de site, grâce à la propriété is_block_theme située dans la réponse API du point de terminaison wp/v2/themes (ticket #58123) ;
• Un point de terminaison a été ajouté afin d’obtenir les révisions des styles globaux, accessible sur /wp/v2/global-styles/revisions (ticket #58524) ;
• WP_REST_Templates_Controller a été modifié afin d’inclure un champ modified pour connaître la date de modification des modèles et des éléments de modèles (ticket #58540).

Thèmes

La nouvelle fonction publique wp_get_remote_theme_patterns() a été ajoutée afin d’effectuer des requêtes sur les patterns provenant du theme.json et se substitue aux précédents usages d’API privées (#58460).

Nouveaux crochets d’actions

• bulk_edit_posts (#28112)
• wp_update_user (#57843)
• wp_cache_set_last_changed (#57905)

Nouveaux filtres

• plugins_list (#57278)
• pre_load_textdomain (#58035)
• wp_get_attachment_image_context (#58212)
• get_pages_query_args (#12821)
• cron_memory_limit (56628)
• nav_menu_item_attributes (#57140)
• nav_menu_link_attributes (#57140)
• nav_menu_submenu_attributes (#57140)
• pre_wp_setup_nav_menu_item (#56577)
• site_editor_no_javascript_message (#56228)
• image_edit_thumbnails_separately (#57685)
• wp_navigation_should_create_fallback (#58750)
• wp_min_priority_img_pixels (#58235)

Crochets d’actions et filtres modifiés

• rest_allowed_cors_headers (#57752) et rest_exposed_cors_headers (#57752)
• edit_custom_thumbnail_sizes a été déprécié et remplacé par image_edit_thumbnails_separately (#57685)

Fichiers dépréciés

• Le fichier wp-admin/media.php a été déprécié. Les personnes visitant cette page seront redirigées sur la médiathèque, avec une notification (ticket #57612).

Mise à jour de bibliothèques externes

Les bibliothèques externes suivantes ont été mises à jour :

• PHPMailer vers la version 6.8.0 (#57873)
• Requests library vers la version 2.0.6 (#58079)
• jQuery vers la version 3.7.0 (#58083)
• Sodium Compat vers la version 1.20.0 (#58224)
• jQuery Migrate vers la version 3.4.1 (#58451)
• npm vers la dernière version disponible (#58623)

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.3 Release Candidate 1. 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 puis adapté à partir du Field Guide de WP 6.3 par Jb Audras.
Merci à Jenny Dupuy pour sa relecture attentive.

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_alloptions permet 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_Query sont dorénavant basées sur du SQL sans variables, afin de pouvoir être mises en cache. Voir le ticket #57298.
• WP_Query ne 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.json prend maintenant en charge davantage de pseudo-classes CSS liées aux liens hypertextes, comme :link ou :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_info et _add_block_template_info en diminuant les appels à la fonction get_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.