register_block_bindings_source( 'client/prix-produit', array(
'label' => 'Prix produit',
'get_value_callback' => 'client_get_prix_produit',
) );
Cette source de liaison personnalisée alimente une dizaine de blocs sur les fiches produit d’un thème bloc développé pour un client e-commerce. Depuis la stabilisation de l’API Block Bindings dans WordPress 6.5, en avril 2024, ce mécanisme permet de connecter un attribut de bloc à une source de données arbitraire, que ce soit un champ ACF, une métadonnée native ou, comme ici, une fonction personnalisée.
Le risque principal identifié après plusieurs mois d’usage : une mise à jour du thème qui renomme un attribut ou change la structure d’un bloc casse silencieusement la liaison, sans erreur PHP visible. Le contenu affiché redevient simplement statique, ce qui passe facilement inaperçu en recette visuelle rapide.
Couvrir les trois types de sources utilisées dans le thème
Le thème combine trois sources de liaison distinctes, chacune avec ses propres risques de régression. La suite de tests PHPUnit vérifie, pour chaque source, que la valeur retournée par get_value_callback correspond bien à la donnée attendue une fois le bloc rendu côté serveur.
core/post-metapour les champs natifs comme le sous-titre- Une source ACF exposée via le plugin Advanced Custom Fields pour les caractéristiques produit
- La source personnalisée
client/prix-produitqui calcule un prix TTC à la volée
Chaque test instancie un post de test avec les métadonnées correspondantes, rend le contenu du bloc avec render_block, puis vérifie que la valeur liée apparaît bien dans le HTML généré, à l’emplacement attendu de l’attribut content.
Détecter une régression après mise à jour du thème
La suite s’exécute automatiquement après chaque montée de version du thème dans l’environnement de recette, avant tout déploiement en production. Le scénario critique reproduit un cas déjà rencontré : un attribut de bloc renommé de metadata.bindings.content.args.key à une nouvelle structure lors d’une mise à jour du thème.
$block_content = do_blocks( $post->post_content );
$this->assertStringContainsString(
'49,90 €',
$block_content,
'Le prix TTC lié doit apparaître dans le rendu du bloc'
);
Ce test échoue immédiatement si la clé de liaison ne correspond plus au nom attendu par la source personnalisée, ce qui aurait permis de repérer la régression du thème avant sa mise en ligne, plutôt que via un signalement client trois jours plus tard.
Isoler les liaisons du cœur des liaisons personnalisées
Un point de vigilance particulier concerne les sources exposées par le cœur de WordPress, comme core/post-meta, dont le comportement peut évoluer d’une version mineure à l’autre. Un test séparé, indépendant du thème, vérifie que ces sources natives se comportent toujours comme documenté par le Block Editor Handbook, afin de ne pas confondre une évolution du cœur avec un bug introduit par le thème.
Gérer les blocs qui perdent leur liaison silencieusement
Un cas particulier mérite un test dédié : que se passe-t-il quand la source de liaison personnalisée n’est plus enregistrée, par exemple après désactivation accidentelle d’une extension ? Sans garde-fou, WordPress affiche simplement le contenu par défaut du bloc, sans avertissement visible pour l’éditeur de contenu.
add_action( 'admin_notices', function() {
if ( ! WP_Block_Bindings_Registry::get_instance()->is_registered( 'client/prix-produit' ) ) {
echo '<div class="notice notice-error">Source de liaison prix produit manquante</div>';
}
} );
La suite de tests vérifie la présence de ce garde-fou en désenregistrant volontairement la source dans un test isolé, puis en contrôlant que la notice d’administration s’affiche correctement.
Documenter les liaisons pour les prochains développeurs
Chaque source de liaison personnalisée est désormais accompagnée d’un test qui documente, en langage de test, le comportement attendu. Cette documentation vivante s’est révélée précieuse lors de l’arrivée d’un nouveau développeur sur le projet, qui a pu comprendre le fonctionnement des liaisons en lisant simplement la suite de tests plutôt qu’en fouillant le code de rendu.
Une source de liaison Block Bindings mal testée finit toujours par casser silencieusement : le rendu reste valide visuellement, seule la donnée dynamique disparaît.
Pour aller plus loin
Cette suite de tests ne couvre volontairement pas l’Interactivity API, qui répond à un besoin différent, celui de l’interactivité côté client plutôt que de la liaison de données côté serveur. Les deux mécanismes cohabitent dans le thème sans se chevaucher, et méritent des stratégies de test distinctes plutôt qu’une suite unique qui mélangerait les deux préoccupations.
