Préparation à WordPress 5.4 : Modifications que les développeurs de thèmes et de plugins doivent connaître

Avec la sortie imminente de WordPress 5.4, il est temps pour les développeurs de plugins et de thèmes de commencer à tester leurs extensions et de s'assurer qu'il n'y a pas de problèmes. Il existe également de nouvelles API pour les fonctionnalités à venir. Hier, l'équipe principale a publié la première version candidate pour la 5.4. La sortie officielle est prévue pour le 31 mars.

Cet article servira de guide rapide avec des liens vers plusieurs changements importants que les développeurs doivent garder à l'esprit dans les semaines à venir. Assurez-vous de tester vos plugins et thèmes.

Développeurs de thèmes

Il y a plusieurs changements que les auteurs de thèmes voudront tester. WordPress 5.4 a quelques fonctionnalités de thème supplémentaires. Il comporte également plusieurs modifications liées au balisage qui pourraient casser les conceptions de thème sur le front-end et dans l'éditeur de blocs. Malheureusement, pour les auteurs de thèmes qui souhaitent prendre en charge plusieurs versions de WordPress, certains de ces changements peuvent signifier un peu de gonflement CSS supplémentaire.

Icônes sociales et blocs de boutons

WordPress 5.4 introduit deux nouveaux blocs : les icônes sociales et les boutons. Le bloc d'icônes sociales permet aux utilisateurs d'insérer des icônes/liens pour jusqu'à 40 réseaux sociaux différents. Le bloc de boutons permet aux utilisateurs de regrouper plusieurs blocs de boutons. Les auteurs de thèmes qui déploient des styles d'éditeur de blocs personnalisés doivent tenir compte de ces nouveaux blocs pour s'assurer qu'ils sont correctement sortis.

Créer des préréglages de dégradé personnalisés

La nouvelle API Gradients permet aux auteurs de thèmes de définir des préréglages de dégradés personnalisés que les utilisateurs peuvent utiliser avec les blocs de groupe ou de bouton. Les auteurs de thèmes devront faire quelques démarches pour améliorer la pollution visuelle des préréglages de dégradé par défaut. Avec un peu de travail, les dégradés peuvent être un outil utile à la disposition de l'utilisateur. Les auteurs de thèmes peuvent également désactiver complètement les dégradés s'ils préfèrent ne pas les prendre en charge.

Modifications du balisage et du style de l'éditeur de blocs

Les auteurs de thèmes qui ont directement ciblé des classes d'éditeurs spécifiques devront vérifier leurs styles d'éditeur de blocs. De nombreuses classes avec le préfixe editor- ont été modifiées pour utiliser le préfixe block-editor- . L'élément wrapper avec la .edit-post-layout__content a été complètement supprimé. Plusieurs éléments wrapper ont été supprimés des blocs et du composant de texte enrichi. Le rembourrage intégré de Core et les marges négatives sur les blocs ont été refactorisés, ce qui est un ajout bienvenu. Peut-être que les auteurs de thèmes n'auront plus à se battre contre plusieurs sélecteurs imbriqués pour fournir une mise en page fonctionnelle de base qui correspond à l'interface.

Ces changements ont déjà brisé plusieurs thèmes que j'ai vus. Il y a de fortes chances que de nombreux auteurs de thèmes aient besoin de mettre à jour leurs styles d'éditeur de blocs.

À une époque où l'équipe de révision des thèmes demande à davantage d'auteurs de thèmes de soumettre des thèmes avec des styles d'éditeur personnalisés, ces types de modifications apportées aux classes et au balisage ne sont pas un regain de confiance. Les développeurs de thèmes peuvent facilement avoir l'impression de mener une bataille perdue d'avance. Cependant, les travaux avancent pour rapprocher le balisage de l'éditeur d'une correspondance un à un avec le frontal. À un moment donné, les auteurs de thèmes ne peuvent qu'espérer qu'ils n'auront plus besoin de faire face à ce type de changements tout en prenant en charge les utilisateurs sur plusieurs versions de WordPress. Pour l'instant, ils sont dans une phase de transition quelque peu chaotique.

Balisage du calendrier et changements de classe

L'équipe principale a modifié le balisage de la fonction get_calendar() , qui affecte également le widget Calendrier. La sortie du calendrier n'a plus d'élément <tfoot> . Au lieu de cela, les liens du mois précédent et suivant ont été déplacés vers un élément <nav> sous l'élément <table> .

La sortie du calendrier ajoute ou modifie également plusieurs ID et classes :

• .wp-calendar-table ajouté à l'élément wrapper.
• .wp-calendar-nav ajouté à l'élément wrapper de navigation.
• .wp-calendar-nav-next remplace l'ID #next sur le lien du mois suivant.
• .wp-calendar-nav-prev remplace l'ID #prev sur le lien du mois précédent.

Ce sont des changements de rupture. Tout CSS personnalisé ciblant l'ancien code HTML ou les anciens identifiants devra être mis à jour.

Bloquer les développeurs

Pour les développeurs de plugins qui créent des blocs personnalisés, WordPress 5.4 introduit plusieurs nouvelles API et outils pour travailler avec le système de blocs.

Bloc d'échafaudage

Les développeurs ont un nouveau package NPM pour créer rapidement un plugin de bloc. Avec une seule commande de npm init @wordpress/block <plugin-name> le script créera un nouveau répertoire et construira les fichiers PHP, CSS et JavaScript appropriés nécessaires à la construction d'un plugin de bloc. Les développeurs peuvent utiliser les outils JavaScript modernes par défaut ou choisir éventuellement d'utiliser une version ES5.

L'intention du package d'échafaudage de blocs est que les auteurs de plugins créent des plugins à bloc unique qui finiront par se retrouver dans le répertoire officiel des blocs.

API de collecte de blocs

L'API Block Collections fonctionne de la même manière que les catégories. Cependant, ils sont basés sur l'espace de noms. Lorsqu'un développeur de plug-in enregistre une collection personnalisée, tous les blocs qui partagent l'espace de noms de la collection apparaîtront sous une section personnalisée dans l'outil d'insertion de blocs. Cela semble être une façon plus intelligente d'organiser les blocs. Cela sera certainement utile pour les plugins qui créent des bibliothèques de blocs, offrant un moyen automatique de les regrouper.

API de variantes de bloc

La nouvelle API Block Variations permet aux développeurs de blocs de créer essentiellement des copies de bloc avec une variation. Chaque variante enregistrée apparaîtra sous la forme d'un bloc séparé dans l'outil d'insertion de blocs parmi lesquels les utilisateurs pourront choisir.

Un bon exemple de cette fonctionnalité est le nouveau bloc d'icônes sociales. Il s'agit d'un bloc unique avec 40 variantes pour les différents réseaux sociaux.

Autres modifications liées aux développeurs

Il y a quelques autres changements notables qui traversent à la fois le territoire de développement de plugins et de thèmes.

Nouveaux crochets de menu de navigation

Après avoir attendu et attendu et attendu, les développeurs obtiennent enfin des crochets souvent demandés pour ajouter des champs personnalisés à l'écran d'administration du menu de navigation et au personnalisateur. Au moins un billet remonte à 9 ans, mais mieux vaut tard que jamais. Dans le passé, les développeurs devaient utiliser une classe de marcheur personnalisée pour effectuer certaines des personnalisations nécessaires. Cependant, une seule classe de marcheur pouvait être utilisée à la fois, ce qui signifiait que plusieurs plugins qui apportaient des modifications ne fonctionneraient pas ensemble.

L'équipe principale a ajouté le nouveau crochet wp_nav_menu_item_custom_fields sur l'écran d'administration des menus de navigation, qui apparaît avant les boutons "déplacer" pour les éléments de menu individuels. Pour parité avec l'administrateur, les éléments du menu de navigation ont un nouveau wp_nav_menu_item_custom_fields_customize_template dans le personnalisateur. Ces crochets permettront aux développeurs d'ajouter des champs de formulaire personnalisés nécessaires pour ajouter des données personnalisées aux éléments du menu de navigation.

apply_shortcodes () Fonction d'alias

WordPress 5.4 introduit une nouvelle fonction apply_shortcodes() . C'est un alias pour la fonction do_shortcode() . La nouvelle fonction fournit un nom de fonction sémantiquement plus correct. Généralement, les fonctions avec un préfixe do_ attendent une sortie ou un certain type d'action. Les fonctions avec un préfixe de apply_ s'attendent à ce que les données soient renvoyées.

Si vous créez un thème ou un plugin avec des zones compatibles avec les codes courts, vous voudrez passer à la nouvelle fonction. Bien que la fonction do_shortcode() ne soit pas actuellement marquée pour obsolescence, cela devrait être l'objectif final.