wp block-bindings source register n’existe pas en WP-CLI, mais register_block_bindings_source() si, disponible depuis que l’API Block Bindings est devenue publique en avril 2024. C’est cette fonction qui permet, sans écrire de bloc dynamique complet, de connecter un attribut d’un bloc natif à une donnée externe comme Algolia.
Ce tutoriel construit une source Block Bindings qui interroge un index Algolia pour afficher, dans un simple core/paragraph, le nombre de produits actuellement en stock dans une catégorie donnée. Il ne couvre pas la configuration de l’index Algolia lui-même (déjà en place sur ce projet) ni la facturation de l’API, uniquement le branchement côté WordPress.
Étape 1 — Comprendre ce qu’apporte une source personnalisée
Avant Block Bindings, afficher une donnée externe dans un bloc obligeait à créer un bloc dynamique dédié avec son propre render_callback, sa propre interface d’édition, ses propres attributs. Une source Block Bindings personnalisée change l’approche : le bloc reste natif (core/paragraph, core/heading), seul son contenu est « connecté » à une source de données via l’attribut metadata.bindings, sans dupliquer l’interface d’édition existante.
Étape 2 — Enregistrer la source côté PHP
La source est enregistrée au chargement de WordPress, avec un identifiant unique et une fonction de rappel qui retourne la valeur à afficher :
function catalogue_enregistrer_source_algolia() {
register_block_bindings_source(
'catalogue/stock-algolia',
array(
'label' => __( 'Stock Algolia', 'catalogue' ),
'get_value_callback' => 'catalogue_lire_stock_algolia',
)
);
}
add_action( 'init', 'catalogue_enregistrer_source_algolia' );
Étape 3 — Écrire la fonction de lecture avec cache court
La fonction de rappel reçoit les arguments définis dans le binding (ici, l’identifiant de catégorie) et doit retourner une chaîne. Interroger Algolia à chaque affichage de page serait coûteux et fragile en cas de latence réseau ; un transient de courte durée absorbe la charge sans rendre la donnée trop périmée :
function catalogue_lire_stock_algolia( $source_args, $block_instance, $attribute_name ) {
$categorie = $source_args['categorie'] ?? '';
$cle_cache = 'stock_algolia_' . sanitize_key( $categorie );
$valeur = get_transient( $cle_cache );
if ( false !== $valeur ) {
return $valeur;
}
$reponse = catalogue_interroger_algolia( $categorie );
$valeur = $reponse['nbHits'] ?? 0;
set_transient( $cle_cache, $valeur, 5 * MINUTE_IN_SECONDS );
return (string) $valeur;
}
Étape 4 — Connecter l’attribut dans le bloc natif
Côté contenu, le paragraphe natif porte désormais des métadonnées de binding plutôt qu’un texte statique. Cette connexion se fait normalement depuis l’interface de l’éditeur (menu contextuel « Connecter »), mais peut aussi être écrite directement dans le contenu stocké :
<!-- wp:paragraph {"metadata":{"bindings":{"content":{"source":"catalogue/stock-algolia","args":{"categorie":"jardin"}}}}} -->
<p>0</p>
<!-- /wp:paragraph -->
Le texte affiché dans l’éditeur (« 0 » ici) sert de valeur de repli tant que la source n’a pas été résolue ; à l’affichage réel, WordPress appelle get_value_callback et remplace le contenu par la valeur retournée.
Étape 5 — Restreindre l’usage aux blocs pertinents
Une source Block Bindings peut, par défaut, être utilisée sur n’importe quel attribut de n’importe quel bloc compatible. Sur ce projet, il a semblé plus sûr de restreindre son usage aux blocs core/paragraph et core/heading, via le filtre block_bindings_source_ui_allowed_blocks, pour éviter qu’un éditeur ne l’applique par erreur à un attribut d’image ou de lien.
- Restriction aux blocs textuels via le filtre dédié, pour limiter les usages inattendus.
- Transient de cinq minutes, arbitrage entre fraîcheur de la donnée et charge sur l’API Algolia.
- Valeur de repli explicite dans l’éditeur, pour ne jamais afficher un contenu vide en cas d’échec de requête.
Ce que cette approche ne remplace pas
Cette source Block Bindings convient à l’affichage d’une donnée simple et ponctuelle. Elle ne remplace pas un bloc dynamique dès que la mise en forme devient complexe (plusieurs valeurs, mise en page conditionnelle, boucle sur une liste de résultats) : dans ce cas, un render_callback classique reste plus approprié et plus lisible.
Une source Block Bindings personnalisée est un pont, pas un moteur de rendu : elle donne une valeur à un bloc natif, elle ne lui donne pas de mise en page.
En résumé
Connecter Algolia à un bloc natif via Block Bindings évite d’écrire un bloc dynamique complet pour une simple donnée d’affichage, au prix d’une source PHP courte et d’un cache adapté à la volatilité réelle de la donnée. L’API étant publique depuis WordPress 6.5, cette approche est désormais stable pour ce type de cas d’usage ciblé.
