WordPress 6.6 « Dorsey » est disponible. La nouvelle version se concentre sur l’affinage et l’amélioration de plusieurs fonctionnalités introduites dans les versions précédentes. Cependant, de nombreux ajouts permettent au cœur de faire un pas de plus sur la voie de la phase 3 du développement de WordPress.
Au total, 299 billets Core Track sont inclus dans WordPress 6.6, ainsi que 392 améliorations, 462 corrections de bugs et 46 améliorations de l’accessibilité pour l’éditeur de blocs.
Parmi les nombreuses nouvelles fonctionnalités qui arrivent avec WordPress 6.6, les remplacements de compositions de blocs sont celles que nous aimons le plus. Initialement prévues pour WordPress 6.5, puis reportées à la version 6.6, les superpositions de compositions constituent la deuxième implémentation de l’API Block Bindings et nous donnent une meilleure idée de ce qui nous attend dans les prochaines versions de WordPress.
Cependant, les remplacements de compositions ne sont que l’un des nombreux ajouts à la prochaine version de WordPress. Commençons donc notre voyage pour découvrir les nouvelles fonctionnalités et les améliorations les plus intéressantes de WordPress 6.6.
Remplacements de compositions synchronisées
La première mise en œuvre de l’API Block Bindings permettait de connecter les attributs des blocs et les champs personnalisés. Avec WordPress 6.6, une deuxième itération débloque une amélioration des compositions synchronisées appelée Synced Pattern Overrides.
Il existe deux types de compositions de blocs :
- Les compositions de blocs synchronisées
- Les compositions de blocs standard (non synchronisées)
La différence entre les deux types est que toutes les modifications apportées à une composition synchronisée s’appliquent à toutes les occurrences d’une composition sur l’ensemble de votre site. En revanche, les modifications apportées à un modèle de bloc standard n’affectent qu’une instance spécifique de la composition.
Les modifications apportées aux compositions synchronisées se situent entre ces deux extrêmes. Grâce à l’API Block Bindings, vous pouvez désormais créer des compositions de blocs qui conservent la même structure partout sur votre site web et qui changent en synchronisation avec les personnalisations apportées à la structure et au style de la composition dans l’éditeur de site. Cependant, vous pouvez modifier le contenu de la composition sur une instance individuelle sans affecter les autres instances de la même composition sur le site.
Découvrons comment fonctionnent les remplacements de compositions.
Tout d’abord, vous avez besoin d’une composition synchronisée. Vous pouvez la créer de toutes pièces dans l’éditeur de publications ou trouver des compositions synchronisées existantes dans la section Compositions de l’éditeur de site.
Étape 1: Allez dans Composition et dupliquez l’une des compositions existante, par exemple la composition Hero du thème par défaut Twenty Twenty-Four. Ajoutez un nom et définissez la copie comme composition synchronisée.
Étape 2: Naviguez dans la section Mes compositions et trouvez votre nouvelle composition synchronisée. Ouvrez-la dans l’éditeur de site et sélectionnez tous les blocs que vous devez remplacer individuellement.
Allez dans la colonne latérale des réglages des blocs et faites défiler vers le bas jusqu’à la section Avancé. Vous y trouverez un bouton, Activer les remplacements.
Lorsque vous cliquez sur le bouton, vous êtes invité à ajouter un nom et à définir le type de composition.
Étape 3: Répétez le même processus pour chaque bloc que vous voulez remplacer. Lorsque vous avez terminé, créez un nouvel article ou une nouvelle page et incluez votre composition personnalisée.
Étape 4: modifie le contenu des blocs pour les remplacer et enregistre le billet. Enfin, vérifie le résultat sur le front-end.
Et voilà, vous avez terminé. Vous pouvez ajouter n’importe quel nombre de ces compositions n’importe où sur votre site web, et chaque nouvelle instance affiche le même contenu d’origine mais est prête pour votre personnalisation.
Maintenant, vérifions le code de ces compositions. Retournez à la section Compositions de l’éditeur de site. Sélectionnez Mes compositions et ajoutez votre composition. Ensuite, ouvrez le menu Options et sélectionnez Éditeur de code pour afficher le code de la composition.
Dans notre exemple, le code devrait ressembler à ce qui suit :
<div class="wp-block-group">
<!-- wp:heading {
"textAlign":"center",
"level":1,
"metadata":{
"bindings":{
"__default":{
"source":"core/pattern-overrides"
}
},
"name":"Hero title"
},"fontSize":"x-large"} -->
<h1 class="wp-block-heading has-text-align-center has-x-large-font-size">A commitment to innovation and sustainability</h1>
<!-- /wp:heading -->
...
</div>Dans le délimiteur de bloc, vous remarquerez la propriété metadata.bindings. Celle-ci rend le bloc Heading modifiable. La liaison __default indique à WordPress de connecter tous les attributs pris en charge à une source spécifique, qui est « core/pattern-overrides ».
La même propriété s’applique à tous les blocs que vous devez rendre modifiables. Voir, par exemple, le bloc Bouton:
<div class="wp-block-buttons">
<!-- wp:button {
"metadata":{
"bindings":{
"__default":{
"source":"core/pattern-overrides"
}
},
"name":"Hero button"
}
} -->
<!-- /wp:button -->
<div class="wp-block-button">
<a class="wp-block-button__link wp-element-button">About us</a>
</div>
...
</div>Maintenant, retournons à l’éditeur de messages et passons à l’éditeur de code. Le code devrait être similaire à ce qui suit :
<!-- wp:block {
"ref":261,
"content":{
"Hero title":{
"content":"Managed WordPress Hosting"
},
"Hero body":{
"content":"Kinsta is an extension of your business. Fast, secure, feature-rich hosting that makes your work so much easier. Built for WordPress websites and agencies worldwide."
},
"Hero button":{
"text":"Learn more",
"url":"https://kinsta.com/wordpress-hosting/",
"linkTarget":"",
"rel":""
},
"Second button":{
"text":"View pricing",
"url":"https://kinsta.com/wordpress-hosting/pricing/",
"linkTarget":"_blank",
"rel":"noreferrer noopener"
},
"Hero image":{
"id":268,
"alt":"",
"url":"http://wordpress.kinsta.cloud/wp-content/uploads/2024/06/homepage-featured-image.jpg"
}
}
} /-->Ici, vous ne verrez pas de blocs, mais seulement une référence à la composition de bloc et un ensemble de propriétés pour chaque bloc qui sont définies comme modifiables.
Encore une fois, vous pouvez ajouter n’importe quel nombre de compositions de blocs n’importe où sur votre site, et ces compositions correspondront à la même structure et au même design que ceux que vous avez construits dans l’Éditeur de site.
Vous pouvez ensuite modifier le contenu des blocs modifiables individuellement, en conservant la même structure.
Étant donné que les surcharges de compositions sont une implémentation de l’API Block Bindings, nous ne pouvons surcharger que les blocs pris en charge : En-tête, Paragraphe, Image et Boutons.
Vous pouvez approfondir la question des remplacements de compositions dans cette vidéo de WordPress TV et dans cet article de blog de Nick Diego.
Les remplacements de compositions sont sujets à des améliorations et des ajouts futurs. La discussion se poursuit sur GitHub ici et ici.
Modifier les valeurs des champs personnalisés à partir de blocs connectés
WordPress 6.5 a introduit les champs personnalisés comme source de données (core/post-meta) pour les attributs des blocs, ce qui permet aux utilisateurs de connecter les valeurs des champs personnalisés aux blocs. WordPress 6.6 apporte de nouvelles améliorations à cette fonctionnalité, comme la possibilité de modifier les valeurs des champs personnalisés directement à partir du bloc connecté.
Vous pouvez l’essayer vous-même en enregistrant un nouvel ensemble de champs personnalisés à partir d’une extension ou du fichier de fonctions de votre ton thème, en veillant à remplacer show_in_rest par true lors de l’enregistrement du méta de l’article. Voici un exemple :
register_post_meta(
'post',
'book_title',
array(
'show_in_rest' => true,
'type' => 'string',
'single' => true,
'sanitize_callback' => 'sanitize_text_field'
)
);Une fois fait, créez un nouvel article ou une nouvelle page et ajoutez un nouveau champ personnalisé avec le même nom. Ajoutez l’un des blocs pris en charge (c’est-à-dire un bloc Heading) au canevas, passez à l’éditeur de code et modifiez le bloc comme indiqué ci-dessous :
<!-- wp:heading
{
"metadata":{
"bindings":{
"content":{
"source":"core/post-meta",
"args":{
"key":"book_title"
}
}
}
}
} -->
<h2 class="wp-block-heading"></h2>
<!-- /wp:heading -->Sauvegardez l’article/la page et vérifiez le résultat. Vous pouvez maintenant modifier le contenu de l’en-tête directement à partir du bloc. La valeur du champ personnalisé devrait refléter vos modifications.
En outre, un nouveau panneau fournit désormais des infos sur les attributs du bloc connectés aux champs personnalisés, en affichant les attributs du bloc liés aux champs personnalisés.
Cette caractéristique s’accompagne de quelques fonctionnalités connexes :
- Vous pouvez mettre à jour les valeurs des champs personnalisés à partir d’une boucle de requête.
- Si plusieurs blocs sont reliés au même champ personnalisé, ils partagent la même valeur de champ personnalisé et changent en synchronisation avec elle.
- Les utilisateurs peuvent modifier les champs personnalisés uniquement dans les articles auxquels ils sont autorisés.
Dernière remarque : Comme indiqué précédemment, les blocs prenant en charge l’API Block Bindings sont toujours limités à ce qui suit :
| Bloc | Attributs |
| Image | url alt, title |
| Titre | content |
| Paragraphe | content |
| Bouton | url,text, linkTarget, rel |
Améliorations de Data Views
Introduit avec WordPress 6.5, Data Views est une interface utilisateur améliorée pour les collections de modèles, de compositions, d’articles, de médias, et plus encore. La nouvelle interface joue un rôle essentiel dans la phase 3 de la feuille de route de développement – Collaboration – et à ce titre, nous pouvons nous attendre à d’autres améliorations avec les prochaines versions de WordPress, « y compris des améliorations du flux de travail pour affecter des personnes à la révision des articles ou créer des vues personnalisées pour rationaliser les processus. » Depuis WordPress 6.6, la nouvelle interface n’existe que dans l’éditeur de site, mais elle devrait s’étendre à d’autres sections d’administration avec les prochaines versions.
WordPress 6.6 introduit de nouvelles mises en page pour les pages de gestion. La gestion des parties de modèles a été supprimée et intégrée à la section Compositions, tandis que le menu Compositions de l’éditeur de site a été réorganisé en deux sections, avec les parties de modèles en haut et les compositions en bas.
Pour les pages, un nouveau panneau fournit une liste de pages et permet de prévisualiser n’importe quelle page en un seul clic.
Vous verrez également de nouvelles options de mise en page disponibles dans le menu des options d’affichage. (L’icône en haut à droite.)
Parallèlement à ces changements plus importants, les vues de données sont concernées par d’autres améliorations mineures améliorant l’interface et la rendant plus fonctionnelle et informative, comme une nouvelle fonction d’édition en bloc et un badge sur la page d’accueil ou la page des articles.
WordPress 6.6 fait franchir une étape supplémentaire aux vues de données, mais nous n’en sommes encore qu’aux prémices. À l’avenir, nous verrons l’introduction d’une API d’extensibilité pour permettre aux développeurs d’agir directement sur les vues. Pour un regard plus approfondi sur l’avenir des vues de données, consulte Data Views Update – June 2024 par Anne McCarthy.
Autres améliorations apportées à l’éditeur de blocs
WordPress 6.6 apporte 8 versions de Gutenberg dans le noyau – de 17.8 à 18.5 – avec de nombreuses améliorations de l’interface, de la bibliothèque React, de l’API de bloc, et bien plus encore. En voici quelques-unes :
Un nouveau flux de publication
Avec la version 6.6, la colonne latérale des réglages d’article ou de page a été nettoyée et rendue plus légère et plus cohérente. Avec cette itération, le processus d’unification entre l’éditeur d’articles et l’éditeur de site fait un pas en avant, et les deux éditeurs ont désormais le même flux de publication.
L’expérience de publication a été standardisée, et un nouveau panneau État & visibilité vous permet de définir le statut de l’article/de la page dans une position plus pratique.
D’autres changements concernent les contrôles Image mise en avant et Extrait, qui ont été déplacés en haut de la colonne latérale, ainsi que le menu Actions amélioré dans le coin supérieur droit.
Voir tous les blocs
Dans les versions précédentes de WordPress, lorsque vous sélectionniez un bloc, l’insertion de bloc n’affichait que le bloc que vous étiez autorisé à ajouter au bloc sélectionné. Par exemple, si vous sélectionniez une colonne, vous ne voyiez que le bloc Colonne dans l’insertion de blocs car vous ne pouviez ajouter qu’une colonne.
À partir de WordPress 6.6, l’insertion de blocs affiche deux groupes de blocs : les blocs que vous pouvez ajouter dans le bloc sélectionné et les blocs que vous pouvez ajouter sous le bloc sélectionné.
Un raccourci clavier pour grouper les blocs
Maintenant, vous pouvez grouper une sélection de blocs avec ⌘ + G sur MacOS ou Ctrl + G sur Windows.
Compositions de blocs dans les thèmes classiques
À partir de WordPress 6.6, les thèmes classiques prennent en charge la même interface de compositions que les thèmes en bloc. Ainsi, si vous utilisez des thèmes classiques sur votre site WordPress, vous bénéficierez de la même expérience riche en matière de gestion des compositions que les thèmes en bloc.
Les images suivantes comparent l’écran des compositions dans WordPress 6.5 et la section d’administration des compositions dans WordPress 6.6.
Vous pouvez désormais modifier, dupliquer, renommer, exporter en JSON et supprimer des compositions comme vous en avez l’habitude avec les thèmes en bloc.
Vous pouvez effectuer des actions en bloc en sélectionnant les compositions individuellement ou en cliquant sur le bouton d’édition en bloc. Des fonctions de tri et de filtrage sont également disponibles.
Vous pouvez aussi créer des compositions comme vous le faites dans les thèmes en bloc. Clique sur le bouton Ajouter une nouvelle composition en haut à droite, et vous serez invité à remplir le formulaire avec les détails de la composition.
Ensuite, vous pouvez construire ou modifier votre composition dans l’éditeur de site comme d’habitude.
Cette mise à jour donne aux utilisateurs de thèmes classiques plus de pouvoir, débloque de nouvelles capacités et rend l’expérience d’édition plus cohérente entre les thèmes classiques et les thèmes en bloc.
Nouveaux outils et fonctionnalités pour les concepteurs et les développeurs de thèmes
WordPress 6.6 apporte tellement de fonctionnalités et d’améliorations puissantes pour les concepteurs et les développeurs de thèmes, et nous sommes heureux de partager ici celles que nous avons le plus aimées. Les concepteurs ont plus de pouvoir lorsqu’il s’agit de styliser leurs pages, grâce aux styles de section, aux images d’arrière-plan à l’échelle du site, à un tout nouvel éditeur d’ombres et à une variation de la mise en page en grille. Et d’autres outils offrent encore plus de flexibilité aux auteurs de thèmes. Plongeons dans le vif du sujet.
Theme.json v.3
WordPress 6.6 apporte également une nouvelle version de theme.json qui est désormais la version 3. Cette nouvelle version modifie la façon de remplacer les propriétés prédéfinies. Maintenant, pour changer les valeurs par défaut de fontSizes ou spacingSizes, vous devez définir defaultFontSizes ou defaultSpacingSizes à false sous settings.typography ou settings.spacing.
Pour résumer :
- Lorsque
defaultFontSizesoudefaultSpacingSizesest défini surtrue, les tailles de police et d’espacement par défaut sont affichées dans l’éditeur, et les thèmes ne sont pas autorisés à créer des pré-réglages à l’aide des slugs par défaut.defaultFontSizesest défini surtruepar défaut. - Si
defaultFontSizesoudefaultSpacingSizesest défini surfalse, les tailles de police et d’espacement par défaut ne sont pas visibles dans l’éditeur, et les thèmes peuvent utiliser les slugs par défaut.
Consultez la note de développement pour un aperçu plus complet de la version 3 de Theme.json.
La spécificité CSS dans WordPress 6.6
Avec WordPress 6.6, la spécificité CSS change, et il est maintenant plus facile de remplacer les styles principaux tout en maintenant la prise en charge des styles globaux.
Jusqu’à la version 6.6, il était souvent difficile de remplacer les styles de base, et les développeurs de thèmes devaient élaborer des règles CSS complexes pour obtenir les résultats souhaités. Avec la version 6.6, les Core Block Styles et Global Styles (theme.json) ont été modifiés en enveloppant le sélecteur existant dans :root :where(...) afin de réduire la spécificité des styles de base à 0-1-0 et de l’uniformiser pour qu’il prenne également en charge les nouveaux styles de section.
Par exemple, .wp-block-image.is-style-rounded img a été mis à jour en :root :where(.wp-block-image.is-style-rounded img).
Les développeurs de blocs qui optent pour les styles globaux sont encouragés à apporter les mêmes modifications à leurs styles afin de les rendre personnalisables via l’interface Styles d’une manière prévisible. Ainsi, si vous avez as un bloc personnalisé avec le style suivant :
.wp-block-custom-block {
padding: 0;
}Vous devrez l’envelopper dans :root :where():
:root :where(.wp-block-custom-block) {
padding: 0;
}Cela permettrait aux utilisateurs de remplacer le rembourrage des blocs par l’interface des styles globaux.
Les développeurs de thèmes sont encouragés à faire de même afin que les styles de blocs puissent être configurés par le biais de l’interface des styles globaux.
Voir également la note de développement pour un aperçu plus approfondi de la spécificité CSS dans WordPress 6.6.
Styles de section
WordPress 6.6 vous permet de styliser des sections individuelles d’un article ou d’une page sans avoir à réappliquer les mêmes styles à plusieurs blocs un par un. Cela signifie que vous pouvez sélectionner plusieurs blocs et blocs enfants et attribuer une variation de style à l’ensemble de la sélection.
Cela est possible grâce à l’extension des variations de style des blocs qui prennent désormais en charge le style des blocs et éléments internes et tirent parti de la spécificité de style réduite pour les styles globaux.
Les variations de style de bloc peuvent être définies et manipulées par le biais des styles globaux uniquement si tu les as enregistrées avec l’une des méthodes suivantes :
- En utilisant les partiels theme.json dans le répertoire /styles du thème.
- En utilisant la fonction
register_block_style - En définissant les variations de style de bloc sous
styles.blocks.variationsdans ton theme.json
Nous allons nous plonger dans le vif du sujet.
Définition des variations de style de bloc à l’aide des partiels theme.json
Comme les variations de style de thème, les variations de style de bloc peuvent avoir leur propre partiel theme.j son sous le répertoire /styles de ton thème.
La différence entre les deux types de variations est que les variations de style de bloc ont une nouvelle propriété de premier niveau blockTypes, qui est un tableau non vide de types de blocs prenant en charge la variation de style de bloc. De plus, une nouvelle propriété slug a été ajoutée « pour assurer la cohérence entre les différentes sources qui peuvent définir les variations de style de bloc et pour découpler le slug de la propriété traduisible title. »
La note de dév fournit l’exemple suivant de theme.json partiel :
{
"$schema": "https://schemas.wp.org/trunk/theme.json",
"version": 3,
"title": "Variation A",
"slug": "variation-a",
"blockTypes": [ "core/group", "core/columns", "core/media-text" ],
"styles": {
"color": {
"background": "#eed8d3",
"text": "#201819"
},
"elements": {
"heading": {
"color": {
"text": "#201819"
}
}
},
"blocks": {
"core/group": {
"color": {
"background": "#825f58",
"text": "#eed8d3"
},
"elements": {
"heading": {
"color": {
"text": "#eed8d3"
}
}
}
}
}
}
}Définition des variations de style de bloc de manière programmatique via register_block_style.
La fonction register_block_style offre une deuxième façon d’enregistrer les variations de style de bloc. Vous pouvez l’utiliser dans le fichier functions.php de votre thème de cette façon :
register_block_style(
array( 'core/group', 'core/columns' ),
array(
'name' => 'light',
'label' => __( 'Light' ),
'style_data' => array(
'color' => array(
'background' => '#973C20',
'text' => '#d2e3c8',
),
'blocks' => array(
'core/group' => array(
'color' => array(
'background' => '#739072',
'text' => '#e3eedd',
),
),
),
'elements' => array(
'link' => array(
'color' => array(
'text' => '#ead196',
),
':hover' => array(
'color' => array(
'text' => '#ebd9b4',
),
),
),
),
),
)
);Maintenant, lorsque vous sélectionnez un bloc Groupe ou Colonnes, le panneau Styles de la colonne latérale du bloc affiche un bouton pour le style de section enregistré.
Vous trouverez un aperçu plus approfondi et plus d’exemples de variations de style de section dans Styling sections, nested elements, and more with Block Style Variations in WordPress 6.6 par Justin Tadlock, dans la dev note d’ Aaron Robertshaw, et dans Block Styles : Extend block style variations pull request.
Définir les variations de style de bloc à l’aide des variations de style de thème
Bien qu’il soit actuellement possible d’utiliser la propriété theme.json styles.variations, cette méthode n’est disponible que temporairement et devrait être bientôt dépréciée. Pour une description plus approfondie, consultez cette section de la dev note.
Pré-réglages de couleur et de typographie
Vous pouvez désormais modifier la palette de couleurs et les familles de polices de votre thème depuis l’interface Styles globaux en sélectionnant l’un des pré-réglages disponibles.
Si votre thème actuel prend en charge les pré-réglages de couleur et de typographie, ils apparaissent sous les réglages Couleurs et Typographie dans les Styles globaux.
Les images suivantes montrent deux palettes de couleurs fournies par Twenty Twenty-Four.
Pour ajouter cette fonctionnalité à vos thèmes, vous devez créer des variations de style qui incluent uniquement les couleurs et la typographie. Les styles ainsi définis seront extraits et utilisés pour générer des pré-réglages.
Sur cette fonctionnalité, voir aussi Amélioration de l’éditeur de base : Améliorer tes designs et Créer des variations individuelles de typographie et de couleur…
Images d’arrière-plan pour l’ensemble du site
À partir de WordPress 6.6, vous pouvez définir des images d’arrière-plan pour l’ensemble du site dans theme.json et dans l’Éditeur de site.
Une image à l’échelle du site est la valeur d’une propriété background-image définie sur l’élément body au niveau du site et apparait sur chaque page du site web.
Dans le site theme.json, pour définir une image d’arrière-plan pour l’ensemble du site, vous pouvez utiliser la propriété backgroundImage.url sous styles.background:
{
"styles": {
"background": {
"backgroundImage": {
"url": "https://example.com/bg.png"
}
}
}
}Dans l’exemple ci-dessus, nous avons défini un chemin absolu vers l’image, mais vous pouvez aussi définir des images d’arrière-plan en utilisant des chemins relatifs à la racine du thème de cette façon.
{
"styles": {
"background": {
"backgroundImage": {
"url": "file:./assets/bg.png"
}
}
}
}Vous pouvez ensuite utiliser les propositions d’image suivantes :
backgroundPositionbackgroundSizebackgroundRepeat
Si vous n’êtes n’es pas un développeur de thème, vous pouvez utiliser des images d’arrière-plan pour l’ensemble du site par l’intermédiaire du panneau Styles de l’éditeur de site. Dans WordPress 6.6, vous trouverez les contrôles appropriés sous Styles > Mise en page.
Il s’agit de la première itération pour les images d’arrière-plan. Pour en savoir plus sur son fonctionnement, ses limites et la suite, consultez la note de développement Site-wide background images in WordPress 6.6.
Variante de mise en page en grille
Une nouvelle variante de mise en page du bloc Groupe vous permet d’afficher les éléments d’un groupe sous forme de grille.
Vous pouvez l’essayer en ajoutant un bloc Groupe au canevas de l’éditeur et en choisissant la disposition Grille dans le panneau des réglages du bloc.
La mise en page en grille se décline en deux types :
- Auto génère automatiquement les lignes et les colonnes de la grille.
- Manuel vous permet de définir le nombre de colonnes que vous voulez ajouter à la grille.
Ajoutez du contenu aux éléments de la grille et redimensionnez-les à l’aide des poignées. Vous pouvez également ajuster la colonne Minimum avec ou le nombre de colonnes en fonction du type de grille sélectionné.
Marges négatives
Vous pouvez désormais définir des marges négatives pour tous les blocs prenant en charge les contrôles de marge. Avant WordPress 6.6, cette fonctionnalité n’était disponible que dans theme.json, alors que maintenant, il est facile d’appliquer des marges négatives aux éléments pour créer des effets de chevauchement.
Note qu’à partir de WordPress 6.6, vous devez ajouter manuellement la valeur négative, comme le montre l’image suivante.
Ombres personnalisées
Avec WordPress 6.6, vous pouvez créer et modifier des ombres personnalisées dans l’interface Styles globaux. Pour créer vos ombres personnalisées, naviguez dans l’Éditeur de site et sélectionnez Ombres dans le menu Styles globaux. Vous y trouverer un panneau Personnaliser. Lorsque vous cliquez sur le bouton +, un nouvel élément vous donne accès à un ensemble de commandes pour personnaliser votre ombre ou la renommer/supprimer.
Pré-réglages personnalisés du rapport hauteur/largeur
Désormais, les développeurs de thèmes peuvent définir des pré-réglages de rapport d’aspect personnalisés en définissant l’option settings.dimensions.aspectRatios dans theme.json.
Changements supplémentaires pour les développeurs
Cependant, les changements pour les développeurs ne se limitent pas aux thèmes. D’autres ajouts et améliorations concernent la bibliothèque React et diverses API.
API Options : Désactivation de l’autoload pour les options de grande taille.
Avant WordPress 6.6, un grand nombre d’options étaient chargées automatiquement à chaque chargement de page. Pour empêcher ce comportement par défaut, les développeurs devaient passer soit "yes"/true, soit "no"/false au troisième paramètre des fonctions add_option() ou update_option(). Cependant, comme ce paramètre était facultatif, avec une valeur par défaut de "yes", de grandes quantités de données inutiles étaient donc chargées à chaque page, avec un impact négatif sur les performances du site.
Pour éviter ce comportement, WordPress 6.6 introduit quelques changements dans l’API des options :
Pour permettre à WordPress de déterminer si une option doit être chargée sur la page en cours, la valeur par défaut du paramètre $autoload de add_option() et update_option() a été modifiée de "yes" à null. Le paramètre accepte désormais l’une des valeurs suivantes :
true: charger l’option sur chaque page pour éviter une requête supplémentaire à la base de données.false: Le paramètre accepte maintenant l’une des valeurs suivantes : : never autoload l’option pour éviter de charger des données sur chaque page.null: maybe autoload, ce qui signifie que la valeur de l’autoload doit être déterminée dynamiquement. Par défaut, les options sont chargées automatiquement à moins qu’elles ne contiennent de grandes valeurs.
Les valeurs de la base de données ont été modifiées en conséquence, et maintenant la valeur d’autoload pour chaque option sera l’une des suivantes :
on: Option de chargement automatique : doit être chargée automatiquement sur chaque page. Elle est ajoutée avec une valeur explicitetrue.off: L’option : ne doit pas être chargée automatiquement et n’est utilisée que sur une seule page d’administration. Il est ajouté avec une valeur explicitefalse.auto: s’appuie sur le comportement de chargement automatique par défaut de WP. Dans WP 6.6, il devrait être chargé automatiquement, mais le comportement peut changer à l’avenir.auto-on: doit être chargé automatiquement. Il est dynamiquement défini surtrue.auto-off: ne doit pas être chargé automatiquement. Il est dynamiquement défini surfalse.
En plus de ces changements, WordPress 6.6 introduit plusieurs fonctions et filtres :
- La fonction
wp_autoload_values_to_autoload()renvoie toutes les valeurs de la base de données qui doivent être chargées automatiquement. - Le filtre
wp_autoload_values_to_autoloadpermet de modifier la liste des options qui doivent être chargées automatiquement. - Le filtre
wp_default_autoload_valuedéfinit la valeur d’une option lorsqu’aucune valeur explicite n’a été définie. - Le filtre
wp_max_autoloaded_option_sizemodifie le seuil au-delà duquel les options ne seront pas chargées automatiquement par défaut. La valeur par défaut est 150000. (150ko)
Cette modification est particulièrement utile pour les sites web complexes comportant de nombreuses extensions et mérite l’attention des développeurs d’extensions. Pour une vue d’ensemble plus approfondie, nous vous recommandons de consulter les pré-réglages de rapport d’aspect personnalisés.
Améliorations apportées à la bibliothèque React
Deux changements majeurs s’appliquent à la bibliothèque React. Tout d’abord, WordPress 6.6 inclut React 18.3, qui ajoute des avertissements pour les dépréciations et d’autres changements pour aider les développeurs à se préparer à React 19 une fois qu’il sera stable.
Deuxièmement, les développeurs peuvent désormais utiliser la nouvelle transformation JSX de React, qui a été introduite pour la première fois avec React 17.
Pour voir de plus près ces changements, voir Préparation à la mise à niveau de React 19 et JSX dans les dev notes de WordPress 6.6.
Améliorations de l’API de bloc
WordPress 6.6 apporte également plusieurs modifications techniques à l’API de bloc, notamment les suivantes :
- API d’extensibilité unifiée
- Améliorations de la détection des variations des blocs actifs
- Changements apportés aux blocs de liens sociaux dans WordPress 6.6
Résumé
Dans ce long article, nous avons exploré de nombreuses fonctionnalités et changements passionnants à venir avec WordPress 6.6, des remplacements de compositions de blocs aux améliorations des vues de données, en passant par les nouvelles fonctionnalités pour les développeurs de thèmes et l’unification des expériences d’édition dans les éditeurs de sites et d’articles. Mais il y a bien d’autres choses que nous n’avons pas abordées dans cet article, comme les retours en arrière pour les mises à jour automatiques.
Si vous voulez aller encore plus loin, vous ne devriez pas manquer une série d’excellentes ressources provenant des contributeurs principaux de WordPress, auxquelles nous nous sommes référés pendant notre test de WordPress 6.6. Parmi les nombreuses ressources, nous vous suggérons WordPress 6.6 Source of Truth d’Anne McCarthy, les ateliers Learn WordPress Online sur Meetup, le blog des développeurs WordPress, les dev notes publiées sur le blog Make WordPress Core, et les mises à jour régulières de Birgit Pauli-Haack sur Gutenberg Times, pour n’en citer que quelques-unes.
Maintenant, c’est à vous de jouer. Avez-vous déjà testé les fonctionnalités de WordPress 6.6 ? Quelle est la fonctionnalité ou le changement qui vous a le plus plu ? Déposez un commentaire ci-dessous et participez à la conversation.
Carlo is a passionate lover of webdesign and front-end development. He has been playing with WordPress for more than 20 years, also in collaboration with Italian and European universities and educational institutions. He has written hundreds of articles and guides about WordPress, published both on Italian and international websites, as well as on printed magazines. You can find him on LinkedIn.
Laisser un commentaire