# register_block_bindings_source pour un bandeau promo relié à un flux externe

> Connecter un bandeau promotionnel à un flux de prix externe sans écrire de route REST maison : une source de liaison personnalisée suffit.

- Auteur : Clément Hadrot
- Publié le : 2025-09-15
- Mis à jour le : 2025-09-15
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/register-block-bindings-source-bandeau-promo-flux-externe/

## L’essentiel

- Une source de liaison remplace une route REST maison
- Le bloc reste un core/paragraph standard, sans code personnalisé
- Le cache du flux évite d'interroger le fournisseur à chaque affichage

« How can I connect a block's content to different sources of data? », pose la documentation officielle de l'API Block Bindings — la réponse tenait jusqu'ici à écrire une route REST personnalisée pour chaque source de données. Depuis l'ouverture de `register_block_bindings_source()` aux développeurs, ce détour n'est plus nécessaire pour un cas aussi simple qu'un bandeau promotionnel affichant un prix qui varie.

Un fabricant de matériel agricole d'occasion voulait afficher, en haut de son site vitrine, le tarif du jour d'un modèle phare — récupéré depuis le flux JSON de son ERP interne, sans que quiconque n'ait à retoucher le contenu de la page à chaque variation de prix. Plutôt qu'un bloc personnalisé complet, une source de liaison suffit à connecter un simple `core/paragraph` à cette donnée externe.

## Déclarer la source de liaison

Une source de liaison se déclare côté serveur avec `register_block_bindings_source()`, à l'initialisation des blocs. Elle expose un callback `get_value_callback` chargé de retourner la valeur affichée à la place du contenu statique du bloc :

```
add_action( 'init', function() {
    register_block_bindings_source(
        'fabricant/flux-prix',
        array(
            'label'              => __( 'Flux de prix ERP', 'fabricant' ),
            'get_value_callback' => 'fabricant_recuperer_prix_flux',
        )
    );
} );

function fabricant_recuperer_prix_flux( array $source_args ) {
    $reference = $source_args['reference'] ?? '';
    $prix      = fabricant_lire_cache_prix( $reference );

    return $prix ? number_format_i18n( $prix, 0 ) . ' €' : '';
}
```

L'argument `$source_args` transporte les paramètres définis dans le contenu du bloc — ici, la référence du modèle à afficher — ce qui permet de réutiliser la même source pour plusieurs bandeaux sans dupliquer le code.

## Relier le bloc côté éditeur

> L'essentiel à retenir : Une source de liaison remplace une route REST maison ; Le bloc reste un core/paragraph standard, sans code personnalisé ; Le cache du flux évite d'interroger le fournisseur à chaque affichage

Depuis l'éditeur, la liaison s'active en cliquant sur l'icône de connexion dans la barre d'outils du paragraphe, une fois la source enregistrée et exposée via le filtre `block_bindings_sources` à l'interface. En arrière-plan, le contenu du bloc stocke cette liaison dans son attribut `metadata.bindings` :

```
<!-- wp:paragraph {
  "metadata": {
    "bindings": {
      "content": {
        "source": "fabricant/flux-prix",
        "args": { "reference": "tracteur-t4-occasion" }
      }
    }
  }
} -->
<p>Prix indicatif</p>
<!-- /wp:paragraph -->
```

Le texte statique « Prix indicatif » reste visible dans l'éditeur si la source ne retourne rien — un filet de sécurité utile si le flux externe est temporairement indisponible, plutôt qu'un bandeau vide qui inquiéterait un visiteur.

## Mettre le flux en cache plutôt que l'interroger en direct

Interroger l'ERP à chaque affichage de page exposerait le site à la moindre lenteur du service interne. La fonction `fabricant_lire_cache_prix()` passe donc par un `transient`, rafraîchi toutes les quinze minutes via une tâche planifiée avec `wp_schedule_event` plutôt qu'à la volée :

```
function fabricant_lire_cache_prix( string $reference ): ?float {
    $cache = get_transient( 'fabricant_prix_' . $reference );
    return $cache !== false ? (float) $cache : null;
}

add_action( 'fabricant_rafraichir_prix', function() {
    $reponse = wp_remote_get( 'https://erp.interne.example/api/prix' );
    if ( is_wp_error( $reponse ) ) {
        return;
    }
    $donnees = json_decode( wp_remote_retrieve_body( $reponse ), true );
    foreach ( $donnees as $ref => $prix ) {
        set_transient( 'fabricant_prix_' . $ref, $prix, 20 * MINUTE_IN_SECONDS );
    }
} );
```

Ce découplage entre lecture (rapide, via `transient`) et récupération (planifiée, via `wp_remote_get`) évite tout ralentissement perceptible sur le rendu de la page, même en cas de panne temporaire du flux distant.

## Ce que cette approche évite d'écrire

- Aucune route REST personnalisée à sécuriser et documenter.
- Aucun bloc dynamique complet avec son propre `render.php` : un `core/paragraph` standard suffit.
- Aucun JavaScript côté éditeur à maintenir pour l'interface de liaison, celle-ci étant fournie nativement par le cœur.

## Limites à connaître

Une source de liaison personnalisée ne couvre que la lecture : elle ne permet pas, à ce jour, de modifier la donnée source depuis l'éditeur — le bandeau reste en lecture seule vis-à-vis du flux ERP, ce qui correspond exactement au besoin ici. Il faut également garder à l'esprit que les blocs bindings ne s'appliquent qu'à certains attributs pris en charge par le bloc cible : pour `core/paragraph`, seul le contenu texte est concerné, pas les couleurs ni les marges.

> Une source de liaison bien nommée, préfixée par le nom du projet, évite les collisions si plusieurs extensions du site en déclarent chacune une.

## Notre verdict

Pour connecter un contenu simple à une donnée externe qui varie, une source de liaison personnalisée reste plus légère qu'un bloc dynamique complet ou qu'une route REST maison. Elle s'appuie sur l'infrastructure déjà fournie par le cœur, ne demande qu'un callback PHP côté serveur, et laisse à l'éditeur la responsabilité de l'interface — un bon compromis quand le besoin se limite à afficher, pas à saisir.