WordPress 5.6 « Simone » est sorti et nous sommes heureux de plonger avec vous dans les fonctionnalités les plus intéressantes et les ajouts fusionnés dans le cœur avec la dernière version WordPress de 2020.
Comme les versions précédentes, WordPress 5.6 comprend plusieurs versions de l’éditeur de blocs qui améliorent l’expérience d’édition pour les utilisateurs de WordPress qui n’ont pas encore installé et mis à jour l’extension Gutenberg sur leurs sites web.
Mais tout ne tourne pas autour de l’éditeur de blocs. Plusieurs fonctionnalités ont été ajoutées au cœur de WordPress, comme un nouveau thème par défaut Twenty Twenty-One, des mises à jour automatiques pour les versions majeures, un meilleur support de PHP 8.0, des mots de passe d’application pour l’authentification de l’API REST.
Et il y a bien plus dans WordPress 5.6. Nous y verrons des améliorations de l’accessibilité, de l’interface utilisateur, des tonnes de corrections de bogues et une énorme liste de changements pour les développeurs.
Si vous souhaitez en savoir plus sur le cycle de développement de WordPress 5.6, consultez les liens ci-dessous :
Prêt à plonger dans le vif du sujet ?
Quoi de neuf avec l’éditeur de blocs
Avec WordPress 5.6, plusieurs versions de l’extension Gutenberg ont été fusionnées dans le cœur, de sorte que les utilisateurs et les auteurs de WordPress devraient remarquer plusieurs améliorations dans l’éditeur. Nous verrons des compositions de blocs améliorées, des compteurs de mots dans le panneau d’information, une navigation au clavier améliorée, une interface utilisateur améliorée par glisser-déposer, et bien plus encore.
Pour une liste plus complète de toutes les améliorations et modifications ajoutées à l’éditeur de bloc, consultez les messages d’annonce de sortie : 8.6, 8.7, 8.8, 8.9, 9.0, 9.1, et 9.2. Les corrections de bogues et les améliorations de performances mises en œuvre dans les versions 9.3 et 9.4 de Gutenberg sont également incluses dans la version 5.6 de WordPress.
Plongeons dans les changements les plus intéressants que nous verrons dans l’éditeur de blocs.
- Blocs, compositions et améliorations de l’UI
- Bloc API V2
- Fonctionnalités supplémentaires et améliorations pour les développeurs de blocs
Blocs, compositions et améliorations de l’UI
Les nouvelles fonctionnalités des blocs, les améliorations et les corrections de bogues amélioreront l’expérience globale d’édition. De plus, un travail important a été réalisé en matière d’accessibilité. Vous trouverez ci-dessous notre sélection des fonctionnalités les plus intéressantes que vous verrez dans l’éditeur de blocs lorsque vous mettrez à jour votre site web en WordPress 5.6.
Contrôles de position pour les vidéos dans le bloc de couverture
Ajoutés aux blocs de couverture depuis Gutenberg 8.6, les contrôles de position pour les vidéos permettent aux utilisateurs de déplacer le point focal et de définir une position personnalisée pour les vidéos. Cette fonctionnalité n’était auparavant disponible que pour les images d’arrière-plan.
Les valeurs de position sont définies en cliquant n’importe où sur le sélecteur de point focal et/ou en utilisant les touches fléchées de votre clavier. Vous pouvez sauter les valeurs par 10 en maintenant la touche shift (voir aussi #22531).
Mises à jour des compositions de blocs
WordPress 5.6 comprend également plusieurs améliorations des compositions de blocs ajoutées avec Gutenberg 8.6.
La mise en page, le texte et la couleur de l’en-tête large et du paragraphe ont été mis à jour (#23858)
L’en-tête dans les deux colonnes de texte a été déplacé hors du bloc de texte et placé au-dessus des colonnes (#23853)
La composition de citation comprend maintenant une image en haut et un séparateur en bas.
Une nouvelle composition de titre et paragraphe a été ajoutée avec Gutenberg 8.7 (#24143).
Une bonne amélioration d’utilisabilité de l’outil d’insertion de blocs est la liste déroulante des catégories de compositions de bloc, qui permet de filtrer les blocs par catégorie. C’est extrêmement utile lorsque vous avez des tonnes de compositions à choisir (#24954).
Prise en charge des sous-titres de vidéo
Les blocs de vidéo prennent désormais en charge les sous-titres de vidéo.
Les éditeurs et les créateurs de contenu doivent fournir des sous-titres vidéo au format WebVTT (Web Video Text Tracks Format), qui est « un format permettant d’afficher des pistes de texte horodatées (telles que des sous-titres ou des légendes) en utilisant l’élément <track> » (#25861).
Une fois que vous aurez chargé vos fichiers .vtt, les visiteurs du site seront autorisés à activer les sous-titres dans leur langue préférée.
Transformer plusieurs blocs en un bloc de colonnes
Une amélioration intéressante de l’utilisabilité est la possibilité de convertir plusieurs blocs sélectionnés en un bloc de colonnes.
Il vous suffit de sélectionner les blocs que vous souhaitez afficher en colonnes, puis de cliquer sur le bouton supérieur droit de la barre d’outils des blocs.
Chaque bloc sélectionné sera converti en une colonne d’un bloc de colonnes.
Motif d’arrière-plan dans le bloc de couverture
Les blocs de couverture peuvent maintenant afficher un motif d’arrière-plan.
Pour ajouter un motif d’arrière-plan, téléversez une image de motif, puis basculez sur l’option Arrière-plan répété (voici tout ce que vous devez savoir sur la médiathèque dans WordPress).
Lorsque vous avez terminé, réglez le sélecteur de point focal en fonction de vos besoins et essayez différentes combinaisons avec des arrière-plans fixes.
Contrôle de taille d’images ajouté au bloc média et texte
Avec Gutenberg 9.1, un nouveau contrôle de la taille des images a été ajouté aux images dans le bloc média et texte.
Les utilisateurs peuvent désormais choisir parmi toutes les tailles d’images disponibles (#24795).
Bloc API V2
Une nouvelle version de l’API Bloc permet aux blocs de rendre leur élément d’enrobage (wrapper). L’objectif de la nouvelle version de l’API est d’alléger le DOM de l’éditeur et de le faire correspondre au contenu de la première page. Selon Ella van Durpe :
Le plus grand avantage de ce système est que les thèmes et les extensions peuvent plus facilement styliser le contenu du bloc si le balisage est le même dans l’éditeur.
La nouvelle version exige de déclarer la propriété de apiVersion sur l’enregistrement de type de bloc :
registerBlockType( name, { apiVersion: 2 } );La nouvelle API nécessite également le hook useBlockProps dans la fonction Edit. Ce hook marque l’élément enveloppant un bloc comme un élément de bloc.
Toute propriété passée à ce hook sera fusionnée et retournée à l’élément wrapper. L’exemple suivant, tiré des notes de développement, montre un cas d’utilisation simple :
import { useBlockProps } from '@wordpress/block-editor';
function Edit( { attributes } ) {
const blockProps = useBlockProps( {
className: someClassName,
style: { color: 'blue' },
} );
return <p { ...blockProps }>{ attributes.content }</p>;
}Pour plus d’exemples, voir l’API de bloc version 2.
Fonctionnalités supplémentaires et améliorations pour les développeurs de blocs
Outre la version 2 de l’API de bloc, voici une liste d’ajouts que les développeurs peuvent consulter.
Block Supports API
Block Supports API permet aux développeurs de blocs d’ajouter des fonctionnalités à leurs blocs. Les couleurs, les arrières-plan, la taille des polices ne sont que quelques-unes des nombreuses fonctionnalités qui peuvent être ajoutées aux blocs grâce à Block Supports API.
WordPress 5.6 introduit également plusieurs nouveaux supports de blocs « pour accroître la cohérence et faciliter l’introduction de ces options dans les blocs ».
Les développeurs peuvent utiliser les nouveaux supports de bloc en ajoutant les clés correspondantes à la propriété supports du fichier block.json ou directement dans la fonction registerBlockType.
L’exemple suivant, tiré de la note de développement Block Supports, montre comment cela fonctionne :
supports: {
color: {
background: true, // Enable background color UI control.
gradient: true, // Enable gradient color UI control.
text: true // Enable text color UI control.
},
fontSize: true, // Enable font size UI control.
lineHeight: true // Enable line height UI control.
}La valeur de style sera automatiquement attachée à l’élément wrapper soit par le biais de la classe has-<value>-<preset-category> (pour les valeurs prédéfinies) ou avec un élément style (pour les valeurs personnalisées).
Pour cette raison, les Block Supports sont destinés à être utilisés avec la nouvelle Bloc API V2.
Les Block Supports peuvent également être utilisés avec des blocs dynamiques.
API createBlocksFromInnerBlocksTemplate
Les développeurs peuvent utiliser le composant InnerBlocks pour créer des blocs personnalisés contenant d’autres blocs. Il s’agit par exemple du bloc Colonnes et du bloc Liens sociaux.
La nouvelle Block API createBlocksFromInnerBlocksTemplate vous permet de créer des blocs à partir du modèle InnerBlocks.
Voir les notes de développement pour une vue plus détaillée et un exemple de code.
Composants de la barre d’outils
Quelques changements affectent également les composants de la barre d’outils :
1. Composant ToolbarGroup
Avant WordPress 5.6, le composant Toolbar permettait aux développeurs de regrouper des options communes dans un conteneur commun. Maintenant, un nouveau composant ToolbarGroup doit être utilisé à la place.
<BlockControls>
<ToolbarGroup>
<ToolbarButton />
</ToolbarGroup>
</BlockControls>2. Composants ToolbarButton et ToolbarItem
L’utilisation d’éléments tabulaires directement comme éléments de la barre d’outils (exemple : <button>)a été déconseillée. Afin d’améliorer l’accessibilité, les éléments de la barre d’outils peuvent être ajoutés en utilisant ToolbarButton pour les boutons et ToolbarItem pour les autres contrôles. L’exemple ci-dessous montre un bouton et un menu déroulant :
<BlockControls>
<ToolbarItem as="button" />
<ToolbarButton />
<ToolbarItem>
{ ( itemProps ) => ( <DropdownMenu toggleProps={ itemProps } /> ) }
</ToolbarItem>
</BlockControls>Désactivation des compositions de blocs du cœur
Les compositions de cœur peuvent maintenant être désactivées en utilisant le drapeau (flag) de support core-block-patterns (#24042)
Désactivation de l’éditeur d’images en ligne
Gutenberg 8.4 a ajouté une fonction d’édition d’images en ligne permettant aux utilisateurs de modifier des images directement à partir de l’éditeur de bloc.
Les développeurs peuvent maintenant désactiver l’éditeur d’images en utilisant le filtre block_editor_settings (#23966) :
add_filter( 'block_editor_settings', function( $settings ) {
$settings['imageEditing'] = false;
return $settings;
} );
Les blocs réutilisables sont transférés dans un paquet séparé
Les blocs réutilisables, qui faisaient auparavant partie du paquet @wordpress/editor, ont été déplacés vers le paquet @wordpress/reusable-blocks pour les rendre disponibles dans d’autres éditeurs.
Un nouveau thème par défaut : Twenty Twenty-One
WordPress 5.6 comprend un tout nouveau thème par défaut. Twenty Twenty-One est un thème WordPress très accessible et minimaliste, avec une mise en page en une seule colonne et une colonne latérale de pied de page.
Le nouveau thème utilise une pile de polices système et une palette de couleurs minimale basée sur des couleurs d’arrière-plan pastel.
Vous pouvez en savoir beaucoup plus sur Twenty Twenty-One en lisant notre article de blog détaillé : Twenty Twenty-One : une plongée profonde dans le nouveau thème par défaut de WordPress
Mises à jour automatiques pour les versions majeures
Les mises à jour automatiques sont une caractéristique essentielle introduite dans WordPress 3.7 visant à améliorer la sécurité des sites et à permettre aux administrateurs de sites de maintenir plus facilement leurs sites WordPress à jour.
Alors que les mises à jour automatiques des versions mineures du cœur ont été implémentées dans les versions précédentes, avec WordPress 5.6, les administrateurs de site peuvent désormais également activer manuellement les mises à jour automatiques pour les versions majeures (plus d’informations à ce sujet dans une seconde).
Malheureusement, cette tâche de maintenance cruciale peut encore être un peu déroutante pour les utilisateurs non techniciens. Vous pouvez en savoir plus sur le fonctionnement des mises à jour automatiques dans notre article Une plongée profonde dans les mises à jour automatiques de WordPress.
Ainsi, WordPress 5.6 introduit une nouvelle interface qui permet aux administrateurs du site d’activer les mises à jour automatiques pour les versions majeures du cœur.
Le scope de cette fonctionnalité a changé pendant le cycle bêta de WordPress 5.6 et la note de développement originale a été déplacée. Selon Jb Audras,
Le champ d’application initial des mises à jour automatiques du cœur a été déplacé pour :
- Fournir quelques mises à jour au design de l’UI.
- Pour les installations existantes, le comportement restera le même qu’aujourd’hui : l’utilisateur doit accepter les mises à jour mineures par défaut, mais il doit accepter les mises à jour majeures (les constantes et les filtres déjà utilisés par les hébergeurs ou les agences auront toujours la priorité).
- Pour les nouvelles installations, le comportement par défaut changera : par défaut, on opte pour les mises à jour mineures et par défaut, pour les mises à jour majeures.
À partir de WordPress 5.6, vous pouvez choisir d’activer les mises à jour automatiques pour les versions majeures du cœur l’écran Mises à jour, où une nouvelle interface utilisateur propose une case à cocher vous permettant d’activer les mises à jour automatiques pour toutes les nouvelles versions de WordPress.
Une fois que vous avez activé les mises à jour automatiques du cœur pour les versions majeures, vous pouvez alors les activer uniquement pour la maintenance et la sécurité en cliquant sur Passer aux mises à jour automatiques uniquement pour les versions de maintenance et de sécurité.
Mises à jour automatiques de version majeure du cœur pour les développeurs
Premièrement, lorsque les mises à jour automatiques de version majeure du cœur sont activées, l’option auto_update_core_major est stockée dans la base de données avec option_value activé. Ainsi, si get_site_option( 'auto_update_core_major' ) renvoie true, la case des mises à jour automatiques est cochée.
Ensuite, WordPress vérifie si les mises à jour automatiques majeures du cœur sont activées par la constante WP_AUTO_UPDATE_CORE ou le filtre allow_major_auto_core_updates et coche la case correspondante.
Les développeurs peuvent également désactiver les mises à jour automatiques de version majeure du cœur en réglant la constante WP_AUTO_UPDATE_CORE sur false ou minor comme indiqué ci-dessous (voir également le contrôle des mises à jour en arrière-plan par le biais de wp-config.php) :
# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );
# Enables minor updates:
define( 'WP_AUTO_UPDATE_CORE', 'minor' );Notez que les valeurs possibles pour WP_AUTO_UPDATE_CORE sont true (all), 'beta', 'rc', 'minor', false.
Une autre option pour désactiver les mises à jour automatiques de version majeure du cœur par défaut est d’utiliser le nouveau filtre allow_major_auto_core_updates :
add_filter( 'allow_major_auto_core_updates', '_return_false' );Quelques commentaires sur l’ajout des mises à jour majeures du cœur
En décembre 2018, Matt Mullenweg a fait part des neuf priorités pour 2019, dont la septième était « Fournir aux utilisateurs un moyen d’accepter les mises à jour automatiques des versions majeures du cœur ». C’est peut-être pour un peu plus tard, mais nous y arrivons.
Les mises à jour automatiques majeures du cœur devraient avoir un grand impact sur la sécurité de WordPress et sur l’expérience globale. Une chose semble claire : d’un point de vue technique, la fonction de mises à jour automatiques majeures du cœur est une tâche complexe qui n’est pas accomplie à 100 % avec la sortie de WordPress 5.6.
Après une discussion approfondie sur Slack, Josepha Haden a résumé les préoccupations et les questions des contributeurs du cœur.
L’objectif principal à long terme est d’avoir des mises à jour automatiques disponibles dans la majorité des sites web WordPress afin d’améliorer la sécurité dans tout l’écosystème WordPress (plus de 30 % du web).
Quoi qu’il en soit, selon Helen Hou-Sandí, développeur principal du cœur :
À mon avis, il y a des choses techniques très difficiles à exécuter et cela nécessite une prise en charge technique TRÈS disciplinée et ciblée du produit
Nous devrions donc voir d’autres changements et améliorations de l’UI des mises à jour automatiques de version majeure du cœur au fil du temps. Voici ce à quoi nous pouvons nous attendre à partir de maintenant :
WordPress 5.6:
- Dans les installations existantes, les mises à jour majeures doivent être activées par l’utilisateur. Toute constante et tout filtre déjà utilisés seront prioritaires. Les mises à jour mineures sont activées par défaut.
- Dans les nouvelles installations, les mises à jour mineures et majeures sont activées par défaut.
WordPress 5.6.1:
- Nous devrions voir quelques changements apportés à l’interface utilisateur des mises à jour automatiques majeures du cœur en fonction des réactions.
WordPress 5.7:
- Un coup de pouce devrait être ajouté à l’écran de santé du site pour toute personne ayant opté pour les mises à jour automatiques majeures.
- Un accord de mise à jour automatique doit être ajouté au processus d’installation dans WordPress 5.7.
La confiance des utilisateurs est une préoccupation majeure des mises à jour automatiques du cœur. Selon Helen :
Je pense que nous pouvons encore faire beaucoup de travail pour solliciter de manière proactive la confiance des utilisateurs, en particulier ceux qui ont eu de mauvaises expériences avec WordPress et/ou des mises à jour
Cependant, chaque site WordPress est un mélange de cœur, d’extensions et de thèmes. Comme l’a dit Helen :
Les mises à jour du cœur sont généralement assez sûres et certaines protections sont intégrées, mais comme les sites peuvent exécuter n’importe quel code à partir de n’importe quelle source, il n’existe pas de « 100 % » pour « tous les types de sites WordPress ».
Les utilisateurs dont les mises à jour automatiques de base sont activées devraient sauvegarder régulièrement leurs sites web ou choisir un hébergeur fournissant des sauvegardes automatiques dans leurs plans.
Les mises à jour automatiques du cœur affecteront également l’expérience globale de mise à jour, y compris les mises à jour automatiques des extensions et des thèmes. C’est ce qu’a noté Joost de Valk dans un commentaire :
Si nous activons les mises à jour automatiques du cœur de WordPress par défaut, nous devrions faire de même pour les extensions. Sinon, les extensions et les thèmes ne peuvent pas se mettre à jour pour les choses qu’ils doivent corriger à cause des mises à jour du cœur. Je pense que les utilisateurs s’attendent également à ce que, si WordPress se met à jour automatiquement, les extensions et les thèmes le fassent aussi.
Changements dans la santé du site dans WordPress 5.6
En plus de toutes les fonctionnalités évoquées ici, WordPress 5.6 apporte également une version améliorée de l’outil de santé du site, qui se comporte désormais différemment en arrière-plan.
Validation des données de santé du site
Un validateur vérifie maintenant les réponses aux questions des tests de santé du site. Le validateur écartera toute réponse non valide, empêchant ainsi l’outil de santé du site de provoquer des erreurs fatales et d’interrompre tout contrôle ultérieur.
Dorénavant, les réponses non valides n’affecteront pas l’indicateur de santé du site (#50145).
Contrôles asynchrones via le point de terminaison REST
L’outil de santé du site est un outil de sécurité puissant qui permet aux propriétaires de sites de connaître l’état de santé de leurs sites web.
Cet outil exécute un certain nombre de tests de sécurité fournissant un aperçu de l’état de santé de votre site web.
Ces tests se divisent en deux catégories : les tests directs, qui s’exécutent au chargement de la page, et les tests asynchrones, qui peuvent prendre un certain temps et s’exécuteront plus tard via des appels JavaScript.
Auparavant, ces tests étaient exécutés par un appel à admin-ajax.php. Avec WordPress 5.6, les choses s’éloignent d’admin-ajax.php et un nouveau point de terminaison (endpoint) de l’API REST sera utilisé à la place. À partir de WordPress 5.6, les tests asynchrones se trouvent dans /wp-json/wp-site-health/v1.
Grâce à la nouvelle amélioration de l’API REST, les extensions et les thèmes sont également capables d’utiliser les points de terminaison REST et ne sont pas limités aux actions Ajax pour leurs tests de santé.
Chaque test asynchrone peut désormais déclarer l’argument has_rest, dont la valeur par défaut est false.
Le code ci-dessous de wp-admin/includes/class-wp-site-health.php montre le tableau des tests asynchrones dans WordPress 5.6 :
'async' => array(
'dotorg_communication' => array(
'label' => __( 'Communication with WordPress.org' ),
'test' => rest_url( 'wp-site-health/v1/tests/dotorg-communication' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_dotorg_communication' ),
),
'background_updates' => array(
'label' => __( 'Background updates' ),
'test' => rest_url( 'wp-site-health/v1/tests/background-updates' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_background_updates' ),
),
'loopback_requests' => array(
'label' => __( 'Loopback request' ),
'test' => rest_url( 'wp-site-health/v1/tests/loopback-requests' ),
'has_rest' => true,
'async_direct_test' => array( WP_Site_Health::get_instance(), 'get_test_loopback_requests' ),
),
'authorization_header' => array(
'label' => __( 'Authorization header' ),
'test' => rest_url( 'wp-site-health/v1/tests/authorization-header' ),
'has_rest' => true,
'headers' => array( 'Authorization' => 'Basic ' . base64_encode( 'user:pwd' ) ),
'skip_cron' => true,
),
),Contrôles de santé du site planifiés :
Si des tests asynchrones ont été mis en place pour éviter les chargements de pages lents et les dépassements de temps, ce problème ne se pose pas pour les tests planifiés.
En gardant cela à l’esprit, en plus de l’argument has_rest que nous avons mentionné ci-dessus, les tableaux de test peuvent également déclarer l’argument async_direct_test (en utilisant le code ci-dessus), qui devrait être une instance appelable d’un test.
Si un test est effectué lors d’un événement planifié, le test n’utilisera pas le point de terminaison de l’API REST mais s’exécutera directement.
Mots de passe d’application pour l’authentification API REST
Les mots de passe d’application sont un nouveau système permettant d’effectuer des requêtes authentifiées auprès de diverses API WordPress.
Les mots de passe ont 24 caractères et se composent de majuscules, de minuscules et de chiffres, qui peuvent être générés manuellement ou par l’API REST.
Pour générer manuellement un nouveau mot de passe d’application, accédez à l’écran de votre profil et faites défiler la page.
Choisissez un nom pour votre mot de passe d’application et confirmez. WordPress affichera votre nouveau mot de passe.
Les mots de passe d’application sont affichés par blocs de 4 caractères, séparés par des espaces, comme affiché ci-dessous :
gsUc UhkU 0ScI gdRd TGoU vrW5Toutefois, les mots de passe peuvent être utilisés avec ou sans espaces :
Les mots de passe d’application renvoyées par le flux d’autorisation ne comportent pas d’espaces. Ils sont strictement là pour permettre à une personne qui regarde une longue chaîne de garder plus facilement sa place si elle la saisit manuellement.
Ils peuvent être utilisés en morceaux, sans espace, ou si vous le souhaitez, vous pourriez probablement ajouter un espace après chaque caractère.
Dans l’écran de profil de l’utilisateur, vous pouvez visualiser, créer et révoquer les mots de passe d’application. Les colonnes Dernière utilisation et Dernière IP vous permettent de trouver facilement les mots de passe qui ne sont plus utilisés et qui doivent être révoqués.
Au moment de la rédaction du présent document, les mots de passe d’application peuvent être utilisés avec les requêtes authentifiées par l’API REST et avec l’ancienne API XML-RPC. Toutefois, nous devrions voir les mots de passe d’application utilisés avec des API supplémentaires à l’avenir. George Stephanis explique :
Le système d’authentification des mots de passe d’application peut également être appliqué aux futures API pour WordPress dès qu’elles seront disponibles. Par exemple, si GraphQL ou d’autres systèmes sont activés dans WordPress, les mots de passe d’application leur fourniront une infrastructure d’authentification solide et bien établie à construire dès le départ.
L’utilisation des mots de passe d’application sur wp-login.php n’est pas possible.
Pour un aperçu plus détaillé de cette fonctionnalité et des informations plus techniques, consultez les ressources suivantes :
- Proposition : Authentification API REST / Mots de passe d’application
- Mots de passe d’application : Guide d’intégration
- Extension de fonction de mots de passe d’application
Un meilleur support pour PHP 8
PHP 8.0 apporte des tonnes de nouvelles fonctionnalités et d’optimisations, ce qui en fait un véritable jalon dans l’évolution du langage. La nouvelle version de PHP introduit de nombreuses mises à jour qui rompent la rétrocompatibilité et de nombreuses fonctionnalités obsolètes ont maintenant été officiellement supprimées. Ainsi, l’ajout du support de PHP 8 dans WordPress est un grand défi.
En fait, même si les contributeurs du cœur de WordPress font de gros efforts pour rendre WordPress 5.6 compatible avec PHP 8, il ne faut pas s’attendre à ce que tous les problèmes possibles soient découverts. L’objectif est d’arriver à un point où tout l’écosystème WordPress est compatible avec PHP 8, ce qui semble vraiment difficile à réaliser pour le moment.
De plus, un site WordPress comprend au moins un thème et un nombre variable d’extensions. On peut donc s’attendre à un bon support de PHP 8 dans le cœur de WordPress, mais il est difficile de croire que des extensions et des thèmes ajouteraient rapidement un support pour PHP 8.
Nous sommes d’accord avec Jonathan Desrosiers lorsqu’il déclare
Il est impossible de connaître l’état du support de PHP 8 au sein de l’écosystème plus large (extensions, thèmes, etc.). Pour cette raison, WordPress 5.6 doit être considéré comme « bêta compatible » avec PHP 8.
« Bêta compatible avec PHP 8 » semble une bonne expression pour représenter un processus en cours qui demande encore beaucoup d’efforts, mais qui reconnaît en même temps le grand travail accompli jusqu’à présent.
Cependant,
Tous les développeurs d’extensions et de thèmes, ainsi que les communautés d’hébergeurs, sont invités à rendre leur code compatible avec PHP 8. Cela permettra à WordPress d’atteindre une véritable « compatibilité totale » plus rapidement, et sans que les utilisateurs finaux aient à en supporter la charge.
Quelques modifications de PHP 8 à connaître
Comme nous l’avons mentionné plus haut, rendre WordPress entièrement compatible avec PHP 8 est un travail en cours. Jonathan Desrosiers fournit une liste des fonctionnalités et des changements de PHP 8 que les développeurs WordPress doivent connaître.
Paramètres nommés
Avec les arguments nommés de PHP, il est maintenant possible de passer des arguments à une fonction en se basant sur le nom du paramètre, plutôt que sur sa position. Cela permet d’écrire du code qui est auto-documenté, les arguments sont indépendants de l’ordre, et les valeurs par défaut peuvent être arbitrairement passées.
Malheureusement, les paramètres actuellement nommés peuvent causer des problèmes de rétrocompatibilité dans WordPress. La raison principale est que les noms des paramètres sont susceptibles d’être modifiés sans préavis jusqu’à la fin de l’audit en cours. Ainsi, au moment où nous écrivons ces lignes :
L’utilisation de paramètres nommés lors de l’appel de fonctions et de méthodes de classe WordPress n’est explicitement pas prise en charge et est fortement déconseillée tant que cet audit n’est pas terminé, car pendant l’audit, les noms des paramètres sont susceptibles d’être modifiés sans préavis. Lorsque cet audit sera terminé, cela sera annoncé dans une future note aux développeurs.
Validations strictes de type/valeur pour les fonctions internes
Lors du passage d’un paramètre de type illégal, les fonctions internes et celles définies par l’utilisateur se comportent différemment. Les fonctions définies par l’utilisateur lancent une TypeError, mais les fonctions internes se comportent de différentes manières, en fonction de plusieurs conditions.
Pour supprimer ces incohérences, en PHP 8, les API d’analyse des paramètres internes génèrent toujours une ThrowError en cas de non-concordance des types de paramètres.
La déclaration de type stricte n’est pas utilisée dans le cœur de WordPress. Cependant, les contributeurs du cœur s’efforcent d’éviter que des types non valides soient transmis aux fonctions du cœur. Tant que ce travail n’est pas terminé, cette modification de PHP 8 peut entraîner des TypeErrors, « surtout si le type d’une valeur est modifié de manière incorrecte par du code accroché à un filtre ».
Contrôles de type plus stricts pour les opérateurs arithmétiques et binaires
Dans les versions précédentes de PHP, l’utilisation d’opérateurs arithmétiques et binaires pour un tableau, une ressource ou un objet non surchargé était autorisée, mais le comportement était incohérent et parfois même déraisonnable :
var_dump([] % [42]);
// int(0)Avec PHP 8, le comportement est toujours le même et tous les opérateurs arithmétiques et binaires lancent une exception TypeError lorsque l’opérande est un tableau, une ressource ou un objet non surchargé (voir la RFC).
Il s’agit d’un autre changement qui nécessite un travail supplémentaire de la part des contributeurs du cœur, comme les nombreuses erreurs, les avertissements et les notices de changements.
Encore une fois, en raison des nombreux problèmes non résolus, il est fortement recommandé d’effectuer des tests de compatibilité dans un environnement de staging ou de développement avant de passer à PHP 8 sur votre site web. En savoir plus sur WordPress et PHP 8.0.
Changements supplémentaires pour les développeurs
WordPress 5.6 introduit des tonnes de changements pour les développeurs et nous n’avons pas pu les inclure tous dans notre liste. Mais voici le top 3 qui, selon nous, vaut la peine d’être regardé :
1. Hook d’action wp_after_insert_post
Avant WordPress 5.6, vous pouviez utiliser save_posts ou des actions similaires pour exécuter un code personnalisé après la publication d’un article. Maintenant, WordPress 5.6 introduit le nouveau hook d’action wp_after_insert_post, qui ne se déclenche qu’une fois que les termes et les métadonnées ont été enregistrés.
En outre, plusieurs fonctions ont été mises à jour pour éviter que ces hooks ne soient déclenchés. Le nouveau paramètre $fire_after_hooks a été ajouté aux fonctions wp_insert_posts(), wp_update_post() et wp_insert_attachment(). S’il est défini sur false, il empêche le déclenchement des hooks d’insertion.
Consultez la note de développement pour un aperçu plus détaillé.
2. Typographie
Les fonctions de typographie intval(), strval(), floatval() et boolval() ont été supprimées du cœur en faveur de la typographie directe :
intval()→(int)strval()→(string)floatval()→(float)
Ce changement a des effets directs sur les performances, car la diffusion directe des caractères est environ 6 fois plus rapide que les fonctions de diffusion des caractères.
3. WP_Error Objects
La classe WP_Error a été améliorée pour permettre de fusionner plusieurs instances WP_Error en une seule. Auparavant, vous ne pouviez le faire que manuellement. Désormais, WordPress 5.6 introduit trois nouvelles méthodes pour vous aider à gérer plusieurs instances de WP_Error. Le code ci-dessous est un exemple tiré de la note de développement :
<?php
$error_1 = new WP_Error(
'code1',
'This is my first error message.',
'Error_Data'
);
$error_2 = new WP_Error(
'code2',
'This is my second error message.',
'Error_Data2'
);
// Merge from another WP_Error.
$error_1->merge_from( $error_2 );
// Retrieve all error data, optionally for a specific error code.
$error_1->get_all_error_data( 'code2' );
// Export to another WP_Error
$error_1->export_to( $error_2 );Lectures complémentaires pour les développeurs
Il est impossible de mentionner tous les changements axés sur le développement introduits par WordPress 5.6, mais vous pouvez en apprendre davantage à leur sujet en utilisant les ressources suivantes :
- Mise à jour de la version de jQuery livrée avec WordPress
- Mise à jour du cœur de jQuery en version 3 – partie 2
- WordPress et PHP 8.0
- Framework d’API REST dans WordPress 5.6
- Changements divers axés sur les développeurs dans WordPress 5.6
Résumé
WordPress 5.6 est une version majeure avec des tonnes de fonctionnalités et de changements pour les utilisateurs et les développeurs. Nous sommes toujours ravis de voir comment l’évolution des technologies web affecte directement la sécurité, les performances, l’utilisabilité et l’accessibilité de WordPress.
Mais l’évolution ne s’arrête jamais et nous pouvons déjà jeter un coup d’œil sur les futures dates de sortie potentielles.
À vous de jouer maintenant : Qu’est-ce que vous aimez le plus dans WordPress 5.6 ? Et quelles fonctionnalités aimeriez-vous voir ajoutées à WordPress 5.7 ?
Carlo est un passionné de webdesign et de développement frontend. Il joue avec WordPress depuis plus de 10 ans, notamment en collaboration avec des universités et des établissements d'enseignement italiens et européens. Il a écrit des dizaines d'articles et de guides sur WordPress, publiés à la fois sur des sites web italiens et internationaux, ainsi que dans des magazines imprimés. Vous pouvez trouver Carlo sur X et LinkedIn.
Laisser un commentaire