WordPress 6.1 « Misha » a été publié le 1er novembre 2022. La troisième version majeure de l’année suit WordPress 6.0 Arturo, publié le 24 mai, et WordPress 5.9 Josephine, publié le 25 janvier.
Comme cela arrive toujours, les nouvelles versions de WordPress apportent de nouvelles fonctionnalités, des améliorations et des corrections de bogues des dernières versions de l’extension Gutenberg dans le noyau. Et WordPress 6.1 ne fait pas exception, puisque 11 versions de l’extension Gutenberg ont été fusionnées dans le noyau, de 13.1 à 14.1.
Dans cet article, nous allons jeter un coup d’œil dans les coulisses et présenter les nouvelles fonctionnalités passionnantes à venir avec la nouvelle version majeure de WordPress.
Matias Ventura nous a donné quelques aperçus de la feuille de route de la 6.1, où il a dit que l’objectif de la 6.1 est d’affiner les expériences introduites avec la 5.9 et la 6.0 et de corriger certaines choses à l’approche de la phase 3 de la feuille de route de Gutenberg.
1. Améliorations de l’éditeur de modèles : L’une des principales nouveautés est l’éditeur de modèles. WordPress 6.1 devrait introduire la possibilité de parcourir, de visualiser et de modifier la structure du site.
2. Compositions de bloc : L’objectif est de donner aux compositions de bloc un rôle central dans la création de modèles et de pages, en les adaptant aux types de publication et aux types de publications personnalisés (CPT), en renforçant la fonctionnalité de verrouillage, en améliorant la gestion des compositions enregistrées, etc.
3. Styles et blocs globaux et outils de conception : WordPress 6.1 permettra de gérer les polices web, d’implémenter la typographie responsive et d’étendre la palette d’outils disponibles pour les blocs. Cela dit, examinons de plus près certaines des fonctionnalités les plus puissantes de WordPress 6.1.
Typographie fluide et espacement
WordPress 6.1 ajoute le support de la typographie fluide via des fonctions CSS calc/clamp .
L’expression typographie fluide décrit la capacité du texte à s’adapter à la largeur du viewport, en passant en douceur d’une largeur minimale à une largeur maximale.
C’est quelque chose de différent de ce que vous pouvez réaliser avec les requêtes média, car ces dernières permettent aux thèmes de redimensionner le texte en fonction de tailles de viewport spécifiques, mais ne font rien entre différentes valeurs.
Certains thèmes prennent déjà en charge la typographie fluide. Twenty Twenty-Two, par exemple, utilise la fonction CSS clamp() pour plusieurs tailles de police. Par exemple :
"settings": {
...
"custom": {
"spacing": {
"small": "max(1.25rem, 5vw)",
"medium": "clamp(2rem, 8vw, calc(4 * var(--wp--style--block-gap)))",
"large": "clamp(4rem, 10vw, 8rem)",
"outer": "var(--wp--custom--spacing--small, 1.25rem)"
},
"typography": {
"font-size": {
"huge": "clamp(2.25rem, 4vw, 2.75rem)",
"gigantic": "clamp(2.75rem, 6vw, 3.25rem)",
"colossal": "clamp(3.25rem, 8vw, 6.25rem)"
}
}
}
}Comme vous pouvez le voir dans le code ci-dessus, des valeurs de taille de police fluide sont utilisées pour chaque taille de police.
Maintenant, à partir de WordPress 6.1, les thèmes peuvent générer automatiquement des tailles de police fluides en déclarant la nouvelle propriété typography.fluid comme suit :
"settings": {
....
"typography": {
"fluid": true,
"fontSizes": [
{
"size": "2rem",
"fluid": {
"min": "2rem",
"max": "2.5rem"
},
"slug": "medium",
"name": "Medium"
}
]
}En utilisant typography.fluid et typography.fontSizes[].fluid, la valeur de chaque taille de police est automatiquement calculée à l’aide de la formule suivante :
--wp--preset--font-size--{slug}: clamp({fluid.min}, {fluid.min} + ((1vw - 0.48rem) * 1.592), {fluid.max});Par exemple :
--wp--preset--font-size--large: clamp(2rem, 2rem + ((1vw - 0.48rem) * 1.592), {2.5rem});Notez qu’au moment de la rédaction de cet article, la typographie fluide est une fonctionnalité expérimentale. Vous pouvez plonger dans les détails techniques dans Supports de bloc : ajouter la typographie fluide.
Fluid typography is a significant improvement for building modern #WordPress websites. We just updated @frostwp to include this feature. Here’s a great read from @richard_tabor into what it is and why it matters. https://t.co/Bq5YuHX3wi
— Brian Gardner (@bgardner) August 8, 2022
Voir aussi Comment ajouter la typographie fluide aux thèmes Block de WordPress par Rich Tabor et La typographie fluide avec Gutenberg par Carolina Nymark.
De même que la typographie fluide, WordPress 6.1 introduit également la prise en charge de l’espacement fluide.
Avant WordPress 6.1, il était uniquement possible de définir des valeurs d’espacement personnalisées dans l’éditeur, et les auteurs de thèmes n’étaient pas autorisés à spécifier des valeurs fixes pour les marges intérieures, la marge et l’espace. Il n’était donc pas possible de transférer les paramètres d’espacement d’un thème à l’autre ou de conserver les valeurs d’espacement lors du copier-coller de contenu entre différents sites.
Désormais, les développeurs de thèmes peuvent déclarer la prise en charge de l’espacement fluide à l’aide des paramètres spacing.spacingScale et spacing.spacingSizes[] (voir également Theme.json : Ajouter des préréglages de taille d’espacement et Étendre theme.json pour fournir des préréglages de taille d’espacement).
"settings": {
"spacing": {
"spacingScale":
{
"steps": 0
},
"spacingSizes": [
{
"size": "clamp(1.5rem, 5vw, 2rem)",
"slug": "30",
"name": "1"
},
{
"size": "clamp(1.8rem, 1.8rem + ((1vw - 0.48rem) * 2.885), 3rem)",
"slug": "40",
"name": "2"
},
{
"size": "clamp(2.5rem, 8vw, 6.5rem)",
"slug": "50",
"name": "3"
},
{
"size": "clamp(3.75rem, 10vw, 7rem)",
"slug": "60",
"name": "4"
},
{
"size": "clamp(5rem, 5.25rem + ((1vw - 0.48rem) * 9.096), 8rem)",
"slug": "70",
"name": "5"
},
{
"size": "clamp(7rem, 14vw, 11rem)",
"slug": "80",
"name": "6"
}
],
...
}
}Vous trouverez les propriétés de typographie fluide et d’espacement documentées dans Global Settings & Styles Presets et dans la référence de theme.json API V2.
Édition de blocs de contenu seul
WordPress 6.1 introduit l’édition de contenu seul pour les blocs, les modèles et les compositions. Avec l’édition de contenu uniquement activée, les utilisateurs peuvent uniquement modifier le contenu d’un bloc ou d’un modèle, ce qui les empêche de casser accidentellement la mise en page ou de modifier les styles.
Actuellement, il n’est pas possible d’activer la modification du contenu uniquement à partir de l’interface de l’éditeur visuel. Pour activer cette fonctionnalité, l’attribut templateLock doit être défini sur contentOnly et vous pouvez utiliser l’éditeur de code pour cela.
L’image suivante fournit un exemple simple.
Lorsque l’édition de contenu uniquement est activée sur un bloc ou un modèle, la barre latérale des paramètres change. Vous ne verrez pas les contrôles de paramètres habituels mais une liste des blocs inclus dans le groupe. Vous pouvez sélectionner l’un de ces blocs en cliquant sur le bloc dans le canevas de l’éditeur ou sur l’élément de liste correspondant dans la barre latérale.
Vous pouvez désactiver l’édition de contenu uniquement en cliquant sur le bouton Modifier dans la barre d’outils du groupe.
Une fois que vous avez terminé vos modifications, vous pouvez réactiver l’édition de contenu uniquement en cliquant sur le bouton Terminé.
En outre, les blocs qui n’ont pas de contenu sont masqués dans la vue en liste et ne peuvent pas recevoir de focus dans la liste des blocs.
Vous pouvez en savoir plus sur l’édition du contenu uniquement dans la note de développement et dans cet article de blog de Rich Tabor.
Amélioration des types de blocs
Avec autant de versions de Gutenberg fusionnées dans le noyau, WordPress 6.1 va apporter des tonnes de changements et d’améliorations aux types de blocs existants.
Ajout de la prise en charge des bordures pour le bloc Colonnes
Le bloc Colonnes exploite désormais le nouveau composant BorderBoxControl qui permet aux utilisateurs de WordPress de spécifier des bordures personnalisées pour les colonnes, en définissant également des styles complètement différents pour chaque bordure (voir aussi Colonne : ajouter la prise en charge des bordures aux blocs de colonnes pull request).
Les bordures individuelles peuvent également être définies dans le fichier theme.json comme suit :
"core/column": {
"border": {
"top": {
"color": "#CA2315",
"style": "dashed",
"width": "6px"
},
"right": {
"color": "#FCB900",
"style": "solid",
"width": "6px"
}
}
}Les développeurs peuvent en savoir plus sur le nouveau contrôle dans la Référence du composant – BorderBoxControl.
Contrôles de bordure pour les blocs d’image
Gutenberg 13.8 a introduit la prise en charge de tous les contrôles de bordure pour le bloc Image. Le changement sera ajouté au noyau avec WordPress 6.1, ouvrant la porte à de nouvelles et grandes opportunités pour les créatifs web.
Améliorations du bloc de commentaires
WordPress 6.1 nous apporte également un bloc de commentaires amélioré. À partir de la prochaine version de WordPress, les utilisateurs pourront utiliser des fonctions d’édition plus avancées sur le bloc Commentaires.
Dans l’image ci-dessous, vous pouvez voir la colonne latérale des réglages du bloc Commentaires et les modifications appliquées au titre Commentaires.
Variations du bloc Termes de publication pour les termes de taxonomie personnalisés
Le bloc Termes de publication a été amélioré avec une nouvelle variation de taxonomie personnalisée. Vous pouvez maintenant enregistrer une nouvelle taxonomie personnalisée, disons le type d’article « Acteurs dans un film », et vous pourrez ajouter une liste de termes de taxonomie à l’article actuel ou au type d’article personnalisé.
L’image ci-dessous montre une liste d’acteurs dans un type de publication Film.
Un nouveau filtre Parents pour le bloc Requête
Un nouveau filtre Parents est désormais disponible pour le bloc de requête afin d’afficher les articles et pages hiérarchiques ayant le même parent.
Contrôles de la famille de polices dans le bloc Titre
Le bloc Titre prend désormais en charge les clés de contrôles de famille de polices.
Espaces horizontaux et verticaux dans le bloc Galerie
À partir de WordPress 6.1, un nouveau contrôle d’espacement axial vous permet de définir différents espaces horizontaux et verticaux pour les images dans le bloc Galerie.
Ce changement se traduit par une plus grande flexibilité lors de la création de la mise en page des galeries d’images.
Images mises en avant dans le bloc Couverture
Les images mises en avant font toujours l’objet de beaucoup d’attention, et dans WordPress 6.1, le champ de leur utilisation est encore étendu. À partir de la version 6.1, l’image mise en avant peut être sélectionnée directement dans l’espace réservé du bloc Couverture, comme le montrent les images suivantes.
Ce changement devrait contribuer à créer une expérience utilisateur plus cohérente en rendant plus clair pour l’utilisateur ce qu’il personnalise.
En outre, une entrée pour utiliser l’image mise en avant a été ajoutée au flux de remplacement des médias.
Outils d’apparence pour les liens de navigation des articles
La propriété du paramètre appearanceTools vous permet d’opter pour plusieurs paramètres qui sont désactivés par défaut.
Depuis WordPress 6.1, pour les thèmes prenant en charge la propriété de réglage appearanceTools, vous pouvez personnaliser la couleur du lien et la famille de polices dans le lien de navigation des articles.
Vous pouvez en savoir plus sur la propriété appearanceTools dans notre introduction au thème Twenty Twenty-Two.
Verrouillage de l’intérieur du bloc conteneur en un clic
Un nouveau bouton à bascule permet désormais aux utilisateurs de verrouiller les blocs dans un conteneur de blocs en un seul clic. Cela s’applique aux blocs Groupe, Couverture et Colonne.
Bloc Liste amélioré
Le bloc Liste a été amélioré et exploite désormais les blocs intérieurs.
Ce changement facilite le tri et l’indentation des éléments de la liste et améliore définitivement l’expérience utilisateur.
Prise en charge des pseudo-éléments dans les thèmes de bloc
Les thèmes de bloc peuvent désormais personnaliser l’apparence des éléments et des blocs en fonction de leur état (actif/focus/over).
Voici un exemple d’utilisation de pseudo-sélecteurs avec des liens, tels que définis dans le theme.json de Twenty Twenty-Three :
"styles": {
...
"elements": {
"link": {
"color": {
"text": "var(--wp--preset--color--contrast)"
},
":hover": {
"typography": {
"textDecoration": "none"
}
},
":focus": {
"typography": {
"textDecoration": "underline dashed"
}
},
":active": {
"color": {
"text": "var(--wp--preset--color--secondary)"
},
"typography": {
"textDecoration": "none"
}
},
"typography": {
"textDecoration": "underline"
}
}
}
}Les styles de boutons du code suivant :
"styles": {
...
"elements": {
"button": {
"border": {
"radius": "0"
},
"color": {
"background": "var(--wp--preset--color--primary)",
"text": "var(--wp--preset--color--contrast)"
},
":hover": {
"color": {
"background": "var(--wp--preset--color--contrast)",
"text": "var(--wp--preset--color--base)"
}
},
":focus": {
"color": {
"background": "var(--wp--preset--color--contrast)",
"text": "var(--wp--preset--color--base)"
}
},
":active": {
"color": {
"background": "var(--wp--preset--color--secondary)",
"text": "var(--wp--preset--color--base)"
}
}
}
}
}Vous pouvez voir le résultat dans les images suivantes.
Mais vous pouvez également styliser des éléments au niveau du bloc. La seule différence est que vous devez définir les styles à l’intérieur d’un bloc. À titre d’exemple, le code suivant, extrait du theme.json de Twenty Twenty-Three, applique des styles aux liens du bloc principal Navigation :
"styles": {
"blocks": {
"core/navigation": {
"elements": {
"link": {
":hover": {
"typography": {
"textDecoration": "underline"
}
},
":focus": {
"typography": {
"textDecoration": "underline dashed"
}
},
":active": {
"typography": {
"textDecoration": "none"
}
},
"typography": {
"textDecoration": "none"
}
}
},
"typography": {
"fontSize": "var(--wp--preset--font-size--small)"
}
}
}
}Fonctionnalités supplémentaires et améliorations de l’éditeur de blocs
Bien qu’il s’agisse d’une version de consolidation, WordPress 6.1 apportera tellement de changements et d’améliorations qu’il serait impossible de les énumérer tous dans un seul article (mais consultez cet article d’Anne McCarty pour une liste complète des outils de conception par bloc).
Ici, nous allons nous plonger dans les changements suivants :
Variations de pièces de modèle dans l’Insertion de bloc
Les variations de parties de modèle sont désormais disponibles dans l’insertion de blocs, ce qui facilite l’ajout de parties de modèle à votre site web.
Cette modification rend le processus d’édition plus simple et plus rapide, permettant aux utilisateurs de visualiser rapidement les variations d’une partie de modèle en une seule fois, en quelques clics.
Visualisation de la marge et des marges intérieures
Une petite mais utile amélioration est la mise en évidence des marges et des marges intérieures pendant que l’utilisateur les ajuste. Cela devrait rendre beaucoup plus clair l’espace qui est ajouté à l’intérieur ou à l’extérieur des éléments.
Améliorations de la colonne latérale des réglages
WordPress 6.1 présentera également plusieurs améliorations de l’interface de la colonnea latérale des paramètres.
La colonne latérale des réglages des articles a été légèrement redessinée. Désormais, les champs pour le format des articles, le slug, le modèle et les auteurs sont alignés et ont la même largeur. En outre, le planificateur de publication a été simplifié pour rendre l’expérience plus compréhensible. La section des modèles a également été déplacée dans un popover pour gagner de l’espace et nettoyer l’interface.
En outre, le panneau des modèles a été remplacé par un lien de modèle. Lorsqu’on clique dessus, le lien de modèle affiche le modèle par défaut dans un popover.
Mises à jour du design du popover de publication
Le sélecteur de date dans le popover Publier a été remanié et utilise désormais « les composants WordPress existants et le style Emotion ».
D’autres informations techniques sont disponibles dans les mises à jour du design du popover Publier (DateTimePicker).
Du temps de lecture dans le panneau d’information
Le panneau d’information disponible dans la barre d’outils supérieure a été amélioré et affiche désormais le Temps de lecture en plus des Mots, Caractères, Titres, Paragraphes et Blocs.
Le temps de lecture estimé est calculé sur une moyenne de 189 mots par minute. En savoir plus dans @wordpress/editor : Ajout du temps de lecture estimé à la table des matières dans l’éditeur.
Contrôle de l’espacement des blocs ajouté à l’interface utilisateur des styles
Les utilisateurs peuvent désormais régler l’espacement vertical et horizontal depuis l’interface utilisateur des styles pour les blocs prenant en charge cette fonctionnalité.
Outils de construction nouveaux et améliorés
WordPress 6.1 va également étendre les fonctionnalités du constructeur de site. Les modèles de blocs seront disponibles à plus d’endroits et un plus grand choix de types de modèles améliorera l’expérience d’édition dans l’éditeur de modèles.
Compositions de création pour les types de publication
WordPress 6.0 a introduit les compositions de création de page, qui sont un moyen de fournir une sélection de modèles chaque fois qu’un utilisateur crée une nouvelle page. De cette façon, vous n’avez pas à construire la page à partir de zéro, mais pouvez choisir un modèle à partir d’une modale et remplir le contenu, et vous êtes prêt.
Pour activer cette fonctionnalité, au moins un modèle de bloc doit déclarer la prise en charge des types de blocs core/post-content.
Maintenant, à partir de WordPress 6.1, cette fonctionnalité s’étend à tous les types de publication. Il vous suffit d’inclure core/post-content dans le blockTypes de votre modèle et de définir le postTypes correspondant.
Voyons maintenant comment tirer parti de cette nouvelle fonctionnalité à l’aide d’un exemple pratique. Supposons que vous ayez un type de publication Film.
Tout d’abord, vous devez enregistrer une composition de bloc comme indiqué ici.
Vous pouvez également opter pour la solution de facilité et utiliser l’enregistrement implicite de composition (pour plus de simplicité dans cet exemple, nous utiliserons l’enregistrement implicite de composition).
Créez un fichier PHP pour votre composition de bloc dans un répertoire /patterns du dossier de votre thème (pour cet exemple, nous avons utilisé Twenty Twenty-Two). Ajoutez ensuite le titre suivant :
<?php
/**
* Title: Pattern with columns
* Slug: twentytwentytwo/pattern-with-columns
* Block Types: core/post-content
* Post Types: movie
* Categories: text
*/
?>
<!-- wp:heading -->
<h2>Hello there!</h2>
<!-- /wp:heading -->Et c’est tout. Maintenant, chaque fois que vous créez un nouveau type de publication Movie, une modale Choisir une composition apparaît à l’écran.
Si vous voulez que la modale s’affiche sur plusieurs types de publications, il suffit d’ajouter les slugs correspondants séparés par des virgules :
<?php
/**
* Title: Pattern with columns
* Slug: twentytwentytwo/pattern-with-columns
* Block Types: core/post-content
* Post Types: movie, book
* Categories: text
*/
?>
<!-- wp:heading -->
<h2>Hello there!</h2>
<!-- /wp:heading -->Pour une vue plus détaillée des modèles de création, voir Capacité d’utiliser des modèles de création pour d’autres types de publication que la page.
Plus de types de modèles dans l’éditeur de site
Avec WordPress 6.0, seul un nombre limité de modèles peut être créé dans l’éditeur de site :
À partir de WordPress 6.1, il sera possible de créer un modèle différent pour chaque type de publication individuel.
Et vous pouvez également ajouter et modifier des modèles pour les taxonomies principales et personnalisées, même pour les catégories ou les étiquettes individuelles.
Si vous enregistrez des types de publication personnalisés ou une taxonomie personnalisée, ils seront automatiquement répertoriés dans la boîte de sélection des modèles de l’éditeur de site.
Mais pas seulement. Une fois le type de modèle sélectionné, une modale demande à l’utilisateur s’il veut créer un modèle pour toutes les publications de ce type ou créer un nouveau modèle pour une publication spécifique du type sélectionné.
Ensuite, une nouvelle modale fournit une liste des publications disponibles pour ce type de publication.
Twenty Twenty-Three et autres améliorations de thèmes
WordPress 6.1 propose également un tout nouveau thème par défaut : Twenty Twenty-Three. C’est un thème minimaliste sans images ni fonctionnalités supplémentaires.
Le nouveau thème par défaut rassemble toutes les dernières fonctionnalités d’édition de site en un seul endroit et constitue un bac à sable parfait pour tester les modèles et les parties de modèles, les variations de style, la typographie et l’espacement flexibles, et toutes les fonctionnalités introduites avec les dernières versions de WordPress.
Et pour cette raison, c’est aussi un excellent outil pour apprendre à développer des thèmes, des modèles et des blocs de modèles avec des exemples fonctionnels.
Vous pouvez plonger plus profondément dans le nouveau thème par défaut de WordPress dans notre aperçu approfondi.
Outre le nouveau thème par défaut, WordPress 6.1 apporte également plusieurs améliorations aux thèmes.
Mise à jour de l’en-tête URI dans les thèmes
Avant WordPress 6.1, si un thème portait le même nom qu’un thème disponible dans le répertoire des thèmes de WordPress, un message de mise à jour disponible était affiché à l’utilisateur.
Avec WordPress 6.1, un nouvel en-tête Update URI empêche d’écraser accidentellement les fichiers de thèmes tiers. Cette fonctionnalité est particulièrement utile si vous disposez d’un thème développé en interne portant le même nom qu’un thème disponible dans le répertoire de thèmes de WordPress mais que vous ne souhaitez pas le partager avec la communauté.
Désormais, si la valeur du champ d’en-tête de thème Update URI ne correspond pas à https://wordpress.org/themes/{$slug}/ ou w.org/theme/{$slug}, WordPress ne tentera pas de le mettre à jour.
Si elle est définie, Update URI doit être une URI avec un nom d’hôte unique, comme https://wordpress.org/themes/my-theme/ ou https://example.com/my-theme/.
Les développeurs de thèmes trouveront un aperçu plus approfondi du nouvel en-tête de thème Update URI dans la dev note officielle.
Filtre des thèmes de blocs sous l’écran Ajouter des thèmes
Un nouveau raccourci permet désormais de filtrer les thèmes de blocs lors de l’ajout d’un nouveau thème à votre installation WordPress.
En outre, un nouvel onglet d’aide des thèmes de blocs a été ajouté au même écran.
Changements pour les développeurs
WordPress 6.1 ajoute également une nouvelle API et de nombreuses fonctionnalités et modifications pour les développeurs.
Nouvelle API de persistance des préférences
WordPress 6.1 introduit une toute nouvelle API de persistance des préférences qui enregistre les préférences des éditeurs dans la base de données WordPress au lieu d’un stockage local.
De cette façon, les préférences des utilisateurs peuvent être stockées sur tous les navigateurs et appareils.
À cette fin, le système de persistance précédent dans le paquet @wordpress/data a été déprécié, et un nouveau paquet preferences-persistence a été introduit. Le nouveau paquet enregistre les données des méta utilisateurs via l’API Rest. Les données seront également sauvegardées dans le stockage local comme solution de repli au cas où l’utilisateur se déconnecte ou qu’une requête est interrompue (voir aussi pull #39795).
Prise en charge des styles de boutons dans theme.json
Avec WordPress 6.1, vous pouvez ajouter des styles de boutons à vos thèmes en utilisant theme.json. Cela permet aux développeurs de thèmes d’ajouter une cohérence aux boutons à travers les blocs. Un exemple est le bloc de recherche, mais les blocs tiers bénéficieront également de ce changement.
Pour rendre cela possible, une nouvelle classe wp-element-button sera ajoutée aux éléments de bouton pour partager le même style.
Vous pouvez tester ce changement en ajoutant le code suivant à votre theme.json dans un environnement de développement :
{
"styles": {
"elements": {
"button": {
"color": {
"background": "blue"
}
}
}
}
}Les variations du bloc de recherche prennent maintenant en charge les Vars de requête
WordPress 6.1 prendra en charge les variations du bloc de recherche basées sur les champs de requête. Cela signifie que vous serez en mesure de fournir à vos utilisateurs des boîtes de recherche à utiliser pour rechercher de manière granulaire tout type de contenu.
Dans l’exemple suivant, nous enregistrons une variation de bloc pour un type de message movies. L’exemple est basé sur le tutoriel de Carolina Nymar sur les variations de bloc.
Dans le fichier de fonctions de votre thème (enfant), ajoutez le code suivant :
function movies_editor_assets() {
wp_enqueue_script(
'movies-block-variations',
get_template_directory_uri() . '/assets/block-variations.js',
array( 'wp-blocks' )
);
}
add_action( 'enqueue_block_editor_assets', 'movies_editor_assets' );Maintenant, créez le fichier block-variations.js suivant dans le dossier assets de votre thème (enfant) :
wp.blocks.registerBlockVariation(
'core/search',
{
name: 'movie-search',
title: 'Movie Search Block',
attributes: {
query: {
post_type: 'movies'
}
}
}
);Rechargez maintenant votre tableau de bord WordPress et recherchez une variation du bloc de recherche Movies dans l’insertion de blocs.
Vous pouvez en savoir plus sur les variations de bloc dans la documentation officielle.
Un nouvel élément Boutons dans les Styles globaux
WordPress 5.9 a introduit une interface Styles globaux pour permettre aux utilisateurs de personnaliser les pré-réglages de style pour leurs sites, soit globalement, soit au niveau des blocs.
Avec la première implémentation, vous pouviez personnaliser les couleurs de l’arrière-plan, du texte et des liens. Maintenant, à partir de WordPress 6.1, un nouvel élément boutons a été ajouté au panneau Couleurs pour permettre aux utilisateurs de contrôler l’apparence des boutons sur l’ensemble de leurs sites web.
Cela affecterait le style des boutons dans tout le site, du bloc Boutons au bloc Recherche et aux blocs tiers faisant usage de boutons.
Outils d’apparence disponibles pour tout thème
Avant WordPress 6.1, les Outils d’apparence n’étaient disponibles que dans les thèmes de blocs. Avec la version 6.1, tout thème peut inclure cette fonctionnalité en ajoutant simplement la prise en charge dans son fichier de fonctions :
add_theme_support( 'appearance-tools' );Cela permettrait d’activer tous les réglages suivants en une seule fois:
- bordure : couleur, rayon, style, largeur
- couleur : lien
- espacement : blockGap, margin, padding
- typographie : lineHeight
Nouvelle fonction is_login_screen()
Une nouvelle fonction is_login_screen() vous permet désormais de déterminer si la page actuelle est l’écran de connexion. Les emplacements de connexion personnalisés sont également pris en charge.
Vous pouvez utiliser la nouvelle balise conditionnelle comme suit :
function add_text_to_login() {
if ( is_login_screen() ) {
echo( "<h1>Welcome to Kinsta!</h1>" );
}
}
add_action( 'init', 'add_text_to_login' );Le résultat à l’écran serait le suivant :
Nouveaux contrôles de santé du site pour le Persistent Object Cache et le Full Page Cache
WordPress 6.1 introduit deux contrôles de santé du site pour le Persistent Object Cache et le Page Cache.
Les deux vérifications s’exécutent uniquement sur les environnements de production. Vous pouvez voir les résultats de ces nouveaux tests dans l’onglet Statut de l’écran Santé du site.
Le test Persistent Object Cache détermine si le site utilise un cache d’objets persistants et, si ce n’est pas le cas, recommande de l’utiliser si cela s’avère judicieux pour le site.
En plus du nouveau test, WordPress 6.1 introduit plusieurs nouveaux filtres que les hébergeurs peuvent utiliser dans leurs environnements respectifs.
Avec site_status_persistent_object_cache_url, les hébergeurs peuvent remplacer le lien par défaut « Lire la suite » pour le Persistent Object Cache par un lien personnalisé. Par exemple :
add_filter( 'site_status_persistent_object_cache_url', function() {
return 'https://example.com/persistent-object-cache';
} );Avec site_status_persistent_object_cache_notes, les hôtes peuvent remplacer les notes par défaut pour recommander leur solution préférée de mise en cache des objets. Voici un exemple d’utilisation :
add_filter( 'site_status_persistent_object_cache_notes', function( $notes ) {
$notes = __( 'Custom notes.', 'text-domain' );
return $notes;
} );site_status_persistent_object_cache_thresholds filtre les seuils utilisés pour déterminer s’il faut suggérer l’utilisation d’un cache d’objet persistant. Les valeurs par défaut sont :
$thresholds = apply_filters(
'site_status_persistent_object_cache_thresholds',
array(
'alloptions_count' => 500,
'alloptions_bytes' => 100000,
'comments_count' => 1000,
'options_count' => 1000,
'posts_count' => 1000,
'terms_count' => 1000,
'users_count' => 1000,
)
);Vous pouvez utiliser le filtre comme suit :
add_filter( 'site_status_persistent_object_cache_thresholds', function( $thresholds ) {
$thresholds = array(
'alloptions_count' => 700,
'alloptions_bytes' => 150000,
'comments_count' => 1500,
'options_count' => 1500,
'posts_count' => 2000,
'terms_count' => 1000,
'users_count' => 2000,
);
return $thresholds;
} );site_status_should_suggest_persistent_object_cache est un filtre de court-circuitage qui permet de suggérer l’utilisation d’un cache d’objet persistant et de contourner les contrôles de seuil par défaut. Vous pouvez l’utiliser comme suit :
add_filter( 'site_status_should_suggest_persistent_object_cache', '__return_true' );Le test Cache pleine page vérifie si le site utilise le cache pleine page et si le temps de réponse est OK :
Deux nouveaux filtres permettent également aux hôtes de personnaliser le seuil de réponse et d’ajouter des en-têtes de cache personnalisés à détecter.
Le site_status_good_response_time_threshold filtre le seuil en dessous duquel un temps de réponse est considéré comme bon. La valeur par défaut est de 600 ms (voir aussi Les temps de réponse lents des serveurs affectent les performances).
site_status_page_cache_supported_cache_headers permet aux hébergeurs d’ajouter des en-têtes de cache personnalisés et les callbacks de vérification correspondants. La dev note fournit l’exemple d’utilisation suivant :
add_filter( 'site_status_page_cache_supported_cache_headers', function( $cache_headers ) {
// Add new header to the existing list.
$cache_headers['cf-cache-status'] = static function ( $header_value ) {
return false !== strpos( strtolower( $header_value ), 'hit' );
};
return $cache_headers;
});Les développeurs peuvent plonger plus profondément dans les nouvelles vérifications de l’outil de santé du site dans :
- Proposition : Contrôles de santé du site du Persistent Object Cache et du Full Page Cache
- Nouveaux contrôles de santé du site de cache dans WordPress 6.1
- Portage de l’Audit Full Page Cache de l’extension de performance
- class-wp-site-health.php
Mises à jour de l’outil Create-block
WordPress 6.1 introduit également de nouvelles fonctionnalités et des mises à jour du package @wordpress/create-block disponible pour les développeurs pour échafauder de nouveaux blocs.
Un échafaudage de bloc est la structure de répertoire de callback permettant à WordPress de reconnaître un bloc.
Quelques nouvelles fonctionnalités et plusieurs améliorations sont introduites avec WordPress 6.1. Un nouveau drapeau –variant permet aux développeurs de blocs de choisir une variante de bloc à échafauder. Les modèles internes fournis par l’outil create-block prennent en charge les variantes dynamic et static, ce qui signifie que vous pouvez échafauder un bloc dynamique ou statique respectivement. La valeur par défaut est static.
Vous pouvez utiliser le nouveau drapeau comme suit :
npx @wordpress/create-block my-first-block -variant=dynamicLes développeurs peuvent définir des variantes personnalisées en ajoutant un objet variants à la définition du modèle.
Une fonctionnalité supplémentaire permet désormais aux développeurs de blocs d’ajouter de nouveaux blocs à une extension existante grâce au drapeau --no-plugin.
npx @wordpress/create-block custom-block --no-pluginL’exécution de la commande ci-dessus crée un nouvel ensemble de fichiers de blocs dans un sous-répertoire du répertoire actuel.
Notez que le script n’est pas conscient de son emplacement :
L’appel à
npx @wordpress/create-block block-name --no-plugincréera un nouveau bloc à l’intérieur dufolderNamedirectoryoù il est appelé
Vous pouvez en savoir plus sur les mises à jour de l’outil create-block.
Mise en cache des résultats des requêtes dans WP_Query
WordPress 6.1 modifie la façon dont les requêtes de base de données sont exécutées dans la classe WP_Query. À partir de la version 6.1, les requêtes seront mises en cache avec pour conséquence que si une requête est exécutée plus d’une fois, les résultats seront chargés à partir du cache.
Les sites utilisant la mise en cache d’objets persistants et les sites utilisant la mise en cache en mémoire bénéficieront de ce changement, bien que les avantages pour ces derniers soient moindres.
Par défaut, tous les appels à WP_Query seront mis en cache, mais les développeurs peuvent choisir de ne pas mettre en cache les requêtes en utilisant le paramètre cache_results :
$args = array(
'posts_per_page' => 20,
'cache_results' => false
);
$query = new WP_Query( $args );Vous pouvez également désactiver la mise en cache des requêtes de manière globale à l’aide du hook disable_caching, bien que cela ne soit pas recommandé.
Il convient de noter que certains paramètres de requête ne sont pas pris en compte pour la mise en cache des requêtes. Le plus couramment utilisé de ces paramètres est le paramètre fields. La raison en est que la prise en compte de fields aurait produit des caches multiples pour plusieurs sous-ensembles des mêmes données, entraînant ainsi une dégradation des performances.
Pour un aperçu plus approfondi de la mise en cache de WP_Query, voir Améliorations des performances de WP_Query dans la dev note 6.1.
Parties de modèle dans les thèmes classiques
À partir de WordPress 6.1, les thèmes classiques prennent en charge les parties de modèle basées sur des blocs. Pour ajouter cette fonctionnalité, les thèmes doivent ajouter la prise en charge de block-template-parts comme indiqué ci-dessous :
function add_block_template_part_support() {
add_theme_support( 'block-template-parts' );
}
add_action( 'after_setup_theme', 'add_block_template_part_support' );Les thèmes classiques peuvent inclure des parties de modèle dans les modèles PHP à l’aide de la fonction block_template_part. Vous pouvez en savoir plus sur cette fonctionnalité dans Block-based « template parts » in traditional themes dev note.
Une note à propos de la conversion des images JPEG en WebP
Initialement, il semblait que WordPress 6.1 aurait également introduit un support pour la conversion automatique des images JPEG en WebP.
Cependant, de nombreux contributeurs ont signalé plusieurs problèmes. Plus précisément, il a été noté que :
Les ressources pour générer des images lorsque vous téléversez une image augmenteront considérablement, cependant les ressources pour servir une image seront réduites. Étant donné que le téléversement d’images est très rare par rapport au service d’images, l’effort supplémentaire pour compresser et stocker les images devrait en valoir la peine.
Et :
En fait, cette augmentation spectaculaire de l’utilisation des ressources lors du téléversement d’une image est un très mauvais effet secondaire. Cela signifie que de nombreux téléversements vont échouer et laisser les utilisateurs en plan. Cela augmentera aussi considérablement les demandes de support à la fois pour WordPress et pour les sociétés d’hébergement. Ne croyez pas que cela soit acceptable. Pour cette raison, même si le support multi-mime des images est nécessaire dans WordPress, l’approche actuelle ne semble pas être une bonne solution.
Enfin, après un article de Matt Mullenweg sur WordPress.org, la conversion automatique de JPEG en WEBP a été retirée de WordPress 6.1.
Je suis intéressé par la prise en charge de nouveaux formats et l’amélioration des performances, mais je pense que ce changement poussé par défaut aux utilisateurs lorsqu’ils passent à la version 6.1 est beaucoup pour l’instant, y compris avec certaines des interactions maladroites que les OS ont encore autour des fichiers webp (et HEIC !).
Je suis heureux que la prise en charge du travail pour les fichiers webp et HEIC reste dans le noyau, car nous devrions être libéraux dans ce que nous acceptons et travaillons, mais pas avec le changement pour tout convertir en webp lorsque les JPEG sont téléversés.
C’est un excellent territoire pour une extension canonique, un concept que je pense que chaque équipe Make devrait explorer beaucoup plus comme un endroit pour expérimenter et pousser la fonctionnalité…
Quoi qu’il en soit, les utilisateurs et les développeurs de WordPress peuvent tester la conversion automatique des images JPEG en WebP en installant l’extension Performance Lab du WordPress Performance Group.
Modifications supplémentaires pour les développeurs
En plus des fonctionnalités et des améliorations dont nous avons parlé ci-dessus, WordPress 6.1 introduit plusieurs changements supplémentaires pour les développeurs. Vous voudrez peut-être approfondir ces changements dans les notes de développement :
- Amélioration des performances PHP pour l’enregistrement des blocs de base
- Comportement de callback des blocs de navigation dans WP 6.1
- Pré-réglages de la taille des espaces dans theme.json
- Échapper les noms de tables et de champs avec wpdb::prepare() dans WordPress 6.1
- WP_List_Table::get_views_links() dans WordPress 6.1
- Fonctions et hooks pour les champs obligatoires dans WordPress 6.1
- Déplacement de l’action send_headers vers plus tard dans le chargement
- Amélioration des performances de l’API REST
- Mises à jour des composants de l’éditeur dans WordPress 6.1
- Améliorations de Multisite dans WordPress 6.1
- Diverses modifications du Core pour WordPress 6.1
- Guide des performances pour WordPress 6.1
- Améliorations diverses de l’API REST dans WordPress 6.1
- Changements de l’API de bloc dans WordPress 6.1
- Diverses modifications de l’éditeur pour WordPress 6.1
- Mise à jour de la prise en charge de la mise en page de l’éditeur dans 6.1 après la refactorisation
- Modifications des préférences de l’éditeur de blocs dans WordPress 6.1
- Génération de styles de blocs (Style Engine)
- Valeurs des styles de référence dans theme.json
Résumé
Avec WordPress 6.1, nous assistons à la consolidation des capacités d’édition de sites WordPress. Nous sommes toujours dans la phase deux de la feuille de route à long terme de Gutenberg, mais les outils et les fonctionnalités à notre disposition deviennent plus fiables et plus robustes au fil du temps. WordPress 6.1 apporte la typographie fluide, de nouveaux outils de création de sites, et des tonnes d’améliorations aux blocs existants.
Mais ce n’est pas tout. WordPress 6.1 apporte également des améliorations significatives aux performances du CMS. Deux nouveaux contrôles de la santé du site détectent l’utilisation de Full Page Cache et de Persistent Object Cache, la mise en cache des requêtes améliore les performances de WP_Query et il y a également des améliorations des performances PHP pour l’enregistrement des blocs de base.
En bref, 6.1 est une version que les utilisateurs et les concepteurs de WordPress vont adorer, ainsi que les développeurs, qui bénéficieront de nombreuses améliorations dans plusieurs domaines du CMS.
C’est maintenant à vous de jouer. Qu’est-ce que vous aimez le plus dans WordPress 6.1 ? Avez-vous déjà testé la nouvelle version dans votre environnement de développement ? Partagez avec nous vos réflexions sur WordPress 6.1 dans la section des commentaires ci-dessous.
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