vendredi 25 septembre 2026

À propos

Contact

FSE

Créer une source de liaison ACF Pro pour les Block Bindings natifs

Afficher un champ ACF via l'interface native des Block Bindings plutôt qu'un shortcode : enregistrer une source personnalisée dans un thème bloc, pas à pas.

Par Clément Hadrot • 17 décembre 2024 • 5 min de lecture • Aucun commentaire
Créer une source de liaison ACF Pro pour les Block Bindings natifs

Un client dans l’immobilier utilisait Advanced Custom Fields Pro depuis des années pour ses fiches de biens, avec des champs comme le prix, la surface ou le nombre de pièces affichés jusqu’ici via des shortcodes glissés dans des blocs Paragraphe. Depuis la sortie de la version 6.5 en avril, l’API de Block Bindings permet de connecter n’importe quel bloc natif directement à une source de données, sans shortcode ni bloc dynamique développé de zéro.

Voici comment j’ai créé une source de liaison personnalisée exposant les champs ACF du client directement dans l’interface native des Block Bindings, accessible depuis le panneau des trois points de n’importe quel bloc supporté.

Comprendre ce qu’apporte une source de liaison

Les Block Bindings permettent de connecter la valeur d’un attribut de bloc (le contenu d’un Paragraphe, l’URL d’une Image, la valeur d’un lien) à une source de données externe, en conservant l’interface de blocs standard. Le cœur de WordPress fournit deux sources par défaut, core/post-meta et core/pattern-overrides, mais l’API permet d’en enregistrer de nouvelles via register_block_bindings_source(), exactement ce dont j’avais besoin pour exposer les champs ACF sous un nom clair plutôt que sous leur clé de méta brute.

Enregistrer la source personnalisée

L'essentiel à retenir : register_block_bindings_source expose vos champs ACF dans l'inserteur ; Le champ reste éditable en un clic sur le bloc concerné ; Fonctionne sans shortcode ni bloc personnalisé développé de zéro

La fonction register_block_bindings_source() attend un identifiant unique de source et un tableau d’arguments, dont le plus important est le callback get_value_callback, chargé de retourner la valeur affichée dans le bloc.

add_action( 'init', function() {
    register_block_bindings_source(
        'client-immo/champ-acf',
        array(
            'label'              => __( 'Champ ACF (fiche bien)', 'client-immo' ),
            'get_value_callback' => function( array $source_args, $block_instance ) {
                if ( empty( $source_args['key'] ) ) {
                    return '';
                }
                $valeur = get_field( $source_args['key'], $block_instance->context['postId'] ?? get_the_ID() );
                return is_scalar( $valeur ) ? (string) $valeur : '';
            },
            'uses_context'       => array( 'postId' ),
        )
    );
} );

L’argument uses_context avec postId est essentiel dans un contexte de Query Loop : il garantit que le champ ACF récupéré correspond bien à l’article courant de la boucle, et non systématiquement à l’article affiché en dehors de toute boucle.

Connecter un bloc à la source depuis l’éditeur

Une fois la source enregistrée, un bloc Paragraphe placé dans le template single-bien.html propose, depuis son panneau de réglages (icône de trombone dans la barre d’outils du bloc, ou menu contextuel selon la version), une option Attacher au champ ACF (fiche bien). En pratique, il faut renseigner la clé exacte du champ ACF concerné, généralement via le JSON de bloc directement pour un déploiement fiable en production :

<!-- wp:paragraph {
  "metadata":{
    "bindings":{
      "content":{
        "source":"client-immo/champ-acf",
        "args":{ "key":"prix_bien" }
      }
    }
  }
} -->
<p>Prix indisponible</p>
<!-- /wp:paragraph -->

Le texte « Prix indisponible » placé dans le balisage sert uniquement de contenu de repli, jamais affiché une fois la liaison active et le champ renseigné, mais utile si jamais la source venait à échouer silencieusement pour un article particulier.

Rendre le champ éditable directement depuis le bloc

Pour autoriser la modification du champ ACF directement depuis le bloc lié, sans repasser par l’écran d’édition classique du custom field, il faut ajouter un callback update_value_callback en complément du callback de lecture, chargé d’écrire la nouvelle valeur via update_field() lors de l’édition dans le bloc.

Les limites rencontrées sur ce projet

Deux limites méritent d’être mentionnées honnêtement. D’abord, les Block Bindings ne fonctionnent nativement qu’avec un nombre restreint de blocs et d’attributs (contenu d’un Paragraphe ou d’un Titre, URL et texte alternatif d’une Image, URL d’un lien), ce qui a exclu certains champs répéteur ACF plus complexes du client, restés sur une solution de bloc dynamique classique. Ensuite, les champs de type relation ou galerie d’ACF ne se prêtent pas à ce mécanisme, pensé avant tout pour des valeurs scalaires simples.

  • Champs texte, nombre, sélection simple : parfaitement adaptés aux Block Bindings.
  • Champs répéteur, relation, galerie : restent sur un développement de bloc dynamique dédié.
  • Le rendu final reste indexable normalement, la valeur étant injectée côté serveur au moment du rendu.

Les Block Bindings ne remplacent pas tous les usages d’ACF, mais ils suppriment une bonne partie des shortcodes disséminés dans le contenu, ce qui simplifie grandement la maintenance d’un thème sur la durée.

En résumé

Enregistrer une source de liaison personnalisée pour ACF Pro demande une seule fonction bien construite, avec un callback de lecture et, si besoin, un callback d’écriture. Le gain principal réside dans l’interface d’édition, redevenue native et cohérente avec le reste de l’éditeur de blocs, plutôt que dispersée entre shortcodes et écrans de champs personnalisés séparés.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi