Un attribut de bloc et une donnée reliée par l’API Block Bindings peuvent produire, à l’écran, exactement le même résultat visuel, tout en fonctionnant selon deux logiques de stockage radicalement différentes. Cette confusion revient régulièrement chez des développeurs qui découvrent Block Bindings, disponible en API publique depuis WordPress 6.5 en avril 2024, sans toujours mesurer ce que ce mécanisme change réellement par rapport à un attribut classique. Cet article ne traite pas de la création d’une source de liaison personnalisée, sujet distinct qui mérite son propre développement.
Comprendre cette différence évite un écueil fréquent : croire qu’un champ affiché dans l’inspecteur du bloc reflète toujours le contenu du bloc lui-même, alors qu’il peut en réalité pointer vers une donnée qui vit ailleurs, gérée indépendamment.
Un attribut classique : une valeur figée dans le contenu
Un attribut de bloc déclaré dans block.json, avec une source comme html, text ou attribute, extrait sa valeur directement du HTML enregistré dans le contenu de l’article, au moment de la sauvegarde. Cette valeur devient alors une partie intégrante du contenu, stockée dans la table wp_posts comme n’importe quel autre texte de l’article :
{
"attributes": {
"titre": {
"type": "string",
"source": "html",
"selector": "h3"
}
}
}Modifier ce titre revient à modifier directement le contenu de l’article concerné. Aucune autre partie du site n’est affectée, et aucune source externe n’est consultée au moment de l’affichage : la valeur affichée est celle qui a été enregistrée, telle quelle.
Une donnée liée par Block Bindings : une lecture à chaque affichage
Block Bindings fonctionne à l’inverse : plutôt que de stocker la valeur dans le contenu du bloc, il connecte un attribut à une source externe, relue à chaque affichage du bloc. La déclaration se fait via l’attribut metadata.bindings :
<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"sous_titre_produit"}}}}} -->
<p>Valeur affichée par défaut dans l'éditeur</p>
<!-- /wp:paragraph -->
Ici, le contenu réellement affiché ne provient pas du texte présent entre les balises <p>, mais de la métadonnée d’article nommée sous_titre_produit, lue à chaque affichage du bloc. Modifier cette métadonnée depuis un autre article, un script ou une interface d’administration change immédiatement l’affichage, sans qu’aucune modification du contenu du bloc lui-même ne soit nécessaire.
Ce que cela change pour la maintenance d’un contenu
Cette distinction a une conséquence concrète et souvent sous-estimée : un contenu qui utilise Block Bindings vers une métadonnée d’article partagée entre plusieurs blocs se met à jour partout à la fois dès que la métadonnée change, alors qu’un attribut classique dupliqué sur plusieurs blocs doit être modifié bloc par bloc, un par un.
Les deux mécanismes peuvent coexister sans conflit
Un même bloc peut très bien porter un attribut classique pour un champ, et une liaison Block Bindings pour un autre. Un bloc Paragraphe, par exemple, peut afficher un texte librement saisi tout en liant son attribut textAlign à une source différente si le besoin s’en présente, sans que les deux logiques n’entrent en conflit, chacune restant indépendante de l’autre.
- Un attribut classique convient à un contenu propre à un seul emplacement, qui n’a pas vocation à être partagé ailleurs.
- Une liaison Block Bindings convient à une donnée qui doit rester synchronisée entre plusieurs emplacements ou blocs.
- Les sources natives disponibles au lancement se limitent aux métadonnées d’article (
core/post-meta) et à certaines valeurs detheme.json(core/theme-categoriesnotamment pour la police et la couleur).
Un repère simple pour trancher entre les deux approches : si la même valeur doit apparaître à plusieurs endroits et rester cohérente partout, Block Bindings évite une synchronisation manuelle vouée tôt ou tard à l’oubli.
En résumé
Un attribut de bloc classique enregistre une valeur figée dans le contenu de l’article, tandis qu’une donnée connectée par Block Bindings reste lue depuis sa source réelle à chaque affichage, ce qui permet une synchronisation automatique entre plusieurs emplacements. Ces deux mécanismes ne s’excluent pas : ils répondent à deux besoins différents, et un même bloc peut parfaitement combiner les deux selon les champs concernés.
