Introduite avec WordPress 6.5, l’API Block Bindings reste l’une des fonctionnalités les plus discrètes de l’éditeur, alors qu’elle résout un vrai irritant : afficher la valeur d’un champ personnalisé à l’intérieur d’un bloc natif, sans devoir créer un bloc entièrement sur mesure juste pour ça. Un titre de produit, un prix, une légende dynamique peuvent ainsi s’appuyer directement sur un bloc paragraphe ou image standard, connecté à une source de données.
Sur des projets récents où la question revient souvent (comment éviter de multiplier les blocs personnalisés pour de simples affichages de champs), les block bindings apportent une réponse élégante, à condition de bien comprendre leurs limites actuelles.
Le principe des block bindings
Un bloc « lié » ne stocke plus sa valeur directement dans son contenu, mais référence une source de données externe, interrogée au moment de l’affichage. Dans le contenu brut d’un article, cela se traduit par un attribut metadata.bindings sur le bloc concerné :
<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"core/post-meta","args":{"key":"prix_produit"}}}}} -->
<p>99</p>
<!-- /wp:paragraph -->La valeur affichée dans l’éditeur reflète la donnée réelle au moment de l’édition, mais le bloc redevient en lecture seule côté éditeur pour cet attribut spécifique : il n’est plus possible de taper directement dedans, seule la source de données peut le modifier.
Les sources natives disponibles
Le cœur de WordPress fournit deux sources natives prêtes à l’emploi : core/post-meta, pour lier un champ personnalisé d’article, et core/pattern-overrides, pensée pour permettre à un rédacteur de personnaliser certaines valeurs à l’intérieur d’un motif synchronisé sans casser sa structure globale.
Seuls trois blocs natifs sont compatibles avec cette API au cœur de WordPress : le paragraphe (sur son attribut content), l’image (sur url, alt et title), et le bouton (sur text et url). Cette limitation, volontaire au lancement de la fonctionnalité, s’élargit progressivement au fil des versions.
Déclarer une source personnalisée
Pour aller au-delà de post-meta, la fonction register_block_bindings_source() permet de déclarer une source de données personnalisée, par exemple pour afficher une valeur calculée dynamiquement plutôt qu’un simple champ stocké :
add_action( 'init', function() {
register_block_bindings_source( 'monsite/stock-disponible', array(
'label' => 'Stock disponible',
'get_value_callback' => function( $args, $block ) {
$produit_id = $block->context['postId'] ?? get_the_ID();
$stock = get_post_meta( $produit_id, 'stock', true );
return $stock > 0 ? "En stock ({$stock})" : 'Rupture de stock';
},
) );
} );Cette source apparaît ensuite dans l’interface de l’éditeur comme option de liaison pour les blocs compatibles, exactement au même titre que les champs personnalisés natifs, sans que le rédacteur ait à comprendre le fonctionnement technique sous-jacent.
Lier un bloc depuis l’éditeur
Côté interface, la liaison se configure depuis le menu contextuel du bloc (l’icône représentant une chaîne, dans la barre d’outils du bloc paragraphe ou image), qui propose la liste des sources disponibles. Un rédacteur peut ainsi connecter un paragraphe à un champ personnalisé sans écrire une ligne de code, une fois la source déclarée côté développement.
Utiliser les block bindings dans un motif
Le cas d’usage le plus courant reste un motif de mise en page réutilisable (une fiche produit, par exemple), où chaque instance doit afficher des données différentes selon l’article concerné. Un bloc image lié à core/post-meta sur la clé image_produit, combiné à un bloc paragraphe lié sur prix_produit, permet de construire un motif générique entièrement piloté par les métadonnées de chaque article, sans dupliquer la structure visuelle pour chaque produit.
Limites actuelles à connaître
- Seuls les trois blocs natifs cités plus haut sont pris en charge sans développement additionnel côté bloc lui-même
- Un bloc lié ne peut pas afficher une valeur formatée complexe sans passer par la logique du
get_value_callback - L’interface de configuration des sources personnalisées reste sommaire côté éditeur, avec peu de retour visuel sur les erreurs de configuration
- Un bloc dans un bloc personnalisé (développé sur mesure) doit explicitement déclarer son support des block bindings pour en bénéficier
Avant de créer un bloc personnalisé entier pour afficher trois champs sur une fiche produit, les block bindings méritent d’être essayés en premier : le résultat est souvent suffisant, pour une fraction du code nécessaire.
En résumé
Les block bindings comblent un vrai manque de l’éditeur de blocs : relier des blocs natifs à des données dynamiques sans multiplier les blocs personnalisés pour de simples besoins d’affichage. Encore limitée à trois blocs au cœur de WordPress, l’API gagne en pertinence à mesure que les thèmes et extensions déclarent leurs propres sources, et mérite clairement sa place dans la boîte à outils de tout développeur travaillant avec des motifs et des champs personnalisés.
