Avant WordPress 6.5, connecter un bloc natif comme le paragraphe ou l’image à une donnée dynamique (un champ personnalisé, une valeur de post meta) obligeait presque toujours à créer un bloc dynamique sur mesure, avec son propre render.php. La Block Bindings API change cette logique : elle permet de lier directement un attribut d’un bloc existant à une source de données externe, sans écrire de nouveau bloc.
Cet article présente le fonctionnement de cette API, comment déclarer une source de liaison personnalisée avec register_block_bindings_source(), et dans quels cas elle remplace avantageusement un bloc dynamique classique.
Le principe des liaisons de blocs
Une liaison (binding) associe un attribut précis d’un bloc à une source de données, via une métadonnée stockée dans le contenu de l’article. Par exemple, un bloc paragraphe peut voir son contenu textuel remplacé dynamiquement par la valeur d’un champ personnalisé, sans que ce texte ne soit jamais stocké en dur dans le contenu de l’article :
<!-- wp:paragraph {
"metadata": {
"bindings": {
"content": {
"source": "core/post-meta",
"args": { "key": "prix_produit" }
}
}
}
} -->
<p>Valeur par défaut affichée dans l'éditeur</p>
<!-- /wp:paragraph -->Côté front, WordPress remplace automatiquement le contenu du paragraphe par la valeur actuelle du champ personnalisé prix_produit, sans qu’aucun code PHP supplémentaire ne soit nécessaire pour ce bloc précis. La source core/post-meta est fournie nativement par WordPress.
Les blocs cœur compatibles au lancement
À la sortie de WordPress 6.5, trois blocs natifs prennent en charge les liaisons : le paragraphe (sur son contenu), l’image (sur l’URL et le texte alternatif), et le bouton (sur le texte et l’URL du lien). D’autres blocs cœur devraient suivre dans les prochaines versions, mais dès aujourd’hui, ces trois blocs couvrent déjà une bonne partie des besoins courants : afficher un prix, une légende, ou un lien dynamique sans coder de bloc dédié.
L’interface de l’éditeur affiche une icône de liaison directement dans la barre d’outils du bloc concerné, avec un menu permettant de choisir la source et le champ à connecter, sans manipulation de code pour l’utilisateur final une fois la source enregistrée par le développeur.
Déclarer une source personnalisée
Au-delà des post meta natifs, il est possible d’enregistrer sa propre source de liaison avec register_block_bindings_source(), côté PHP. Cela ouvre la porte à des sources bien plus riches : une valeur calculée, un champ ACF, ou une donnée issue d’une API externe mise en cache.
<?php
add_action( 'init', function () {
register_block_bindings_source( 'wpmoderne/stock-produit', [
'label' => __( 'Stock produit', 'wpmoderne' ),
'get_value_callback' => function ( $source_args, $block_instance ) {
$post_id = $block_instance->context['postId'] ?? get_the_ID();
$stock = get_post_meta( $post_id, '_stock_disponible', true );
return $stock > 0
? sprintf( '%d en stock', (int) $stock )
: 'Rupture de stock';
},
] );
} );Une fois cette source enregistrée, elle apparaît dans le sélecteur de liaisons de l’éditeur pour tous les blocs compatibles, exactement comme les sources natives. Le champ get_value_callback reçoit les arguments de la liaison ainsi qu’une instance du bloc, ce qui donne accès au contexte complet (identifiant de l’article, attributs courants) pour calculer la valeur à afficher.
Différence avec un bloc dynamique classique
La question se pose naturellement : pourquoi utiliser une liaison plutôt qu’un bloc dynamique complet avec son propre render.php ? La réponse tient à la granularité du besoin. Un bloc dynamique reste pertinent pour une structure HTML entièrement sur mesure, avec plusieurs éléments interdépendants. Une liaison, elle, est idéale lorsque la structure correspond déjà à un bloc natif existant, et que seule une valeur ponctuelle doit être dynamique.
- Afficher un prix dans un simple paragraphe déjà stylé comme le reste du contenu : une liaison suffit.
- Afficher une fiche produit complète avec plusieurs zones interdépendantes : un bloc dynamique reste plus adapté.
- Réutiliser la même source sur plusieurs blocs différents (paragraphe, bouton) sans dupliquer de logique : les liaisons brillent particulièrement ici.
Limites actuelles à connaître
Cette première version de l’API reste volontairement circonscrite. Seuls les blocs cœur explicitement listés prennent en charge les liaisons pour l’instant ; un bloc personnalisé doit déclarer lui-même son support via la propriété __experimentalConnections ou l’attribut metadata.bindings pour en bénéficier, ce qui demande un peu de préparation côté bloc. Par ailleurs, l’édition directe dans l’éditeur d’un champ lié est parfois désactivée par la source elle-même (via editable: false), pour éviter que l’utilisateur ne modifie par erreur une valeur censée provenir d’ailleurs.
Une liaison de bloc n’est pas un raccourci pour éviter d’écrire du PHP : c’est un outil pour éviter de dupliquer du HTML déjà bien conçu par les blocs natifs. La distinction compte au moment de choisir la bonne approche.
En résumé
La Block Bindings API, introduite avec WordPress 6.5, ouvre une troisième voie entre le bloc purement statique et le bloc dynamique sur mesure : connecter un attribut précis d’un bloc natif à une source de données externe, sans dupliquer de markup ni écrire de nouveau bloc. Pour des besoins ciblés comme l’affichage d’un champ personnalisé dans un paragraphe existant, c’est aujourd’hui l’approche la plus légère et la plus maintenable.
