# Le filtre render_block modifie chaque bloc affiché sans toucher render_callback

> Un filtre unique intercepte le HTML de tous les blocs affichés, sans réécrire chaque bloc. Utile pour un wrapper commun ou un suivi statistique transversal.

- Auteur : WordPress Développement
- Publié le : 2020-01-13
- Mis à jour le : 2020-01-13
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/filtre-render-block-modifier-affichage-sans-render-callback/

## L’essentiel

- Intercepte le HTML final de tout bloc affiché
- Reçoit le bloc parsé en second argument
- S'applique sans modifier chaque bloc individuellement

`add_filter( 'render_block', 'ma_fonction', 10, 2 );` : cette seule ligne suffit à intercepter le HTML de chaque bloc, natif ou personnalisé, juste après son rendu. Pas besoin de modifier le `render_callback` d'un bloc dynamique en particulier, ni de toucher au fichier `save.js` d'un bloc statique : le filtre agit après coup, sur la sortie déjà générée.

C'est la bonne réponse à un besoin récurrent : ajouter un attribut de suivi, un wrapper commun, une classe conditionnelle, à tous les blocs d'un site, sans aller éditer chaque définition de bloc une par une. Le filtre `render_block` reçoit deux arguments : le contenu HTML déjà rendu, et le tableau représentant le bloc tel qu'il a été analysé par `parse_blocks()`. C'est cette seconde donnée qui rend le filtre réellement exploitable.

## Ce que reçoit exactement le filtre

Le premier paramètre est une chaîne : le HTML final du bloc, après exécution de son éventuel `render_callback`. Le second paramètre est un tableau associatif contenant trois clés utiles : `blockName` (le nom complet du bloc, par exemple `core/paragraph`), `attrs` (les attributs tels que déclarés dans `block.json` ou le fichier PHP d'enregistrement), et `innerBlocks` pour les blocs composés.

Cette structure permet de cibler précisément un type de bloc sans avoir à parser le HTML avec des expressions régulières fragiles. Un simple test sur `blockName` suffit à savoir si l'on doit intervenir ou laisser passer le contenu tel quel.

## Un exemple concret : ajouter un attribut de suivi

> L'essentiel à retenir : Intercepte le HTML final de tout bloc affiché ; Reçoit le bloc parsé en second argument ; S'applique sans modifier chaque bloc individuellement

Voici un cas fréquent : entourer chaque bloc `core/image` d'un attribut `data-bloc` pour un outil de mesure interne, sans modifier le bloc image du cœur.

```
add_filter( 'render_block', function( $contenu, $bloc ) {
    if ( 'core/image' !== $bloc['blockName'] ) {
        return $contenu;
    }

    return preg_replace(
        '/<figure /',
        '<figure data-bloc="image-suivi" ',
        $contenu,
        1
    );
}, 10, 2 );
```

Notez que l'on garde ici une expression régulière ciblée, appliquée une seule fois grâce au dernier paramètre de `preg_replace()`, sur un fragment déjà connu et stable. Le filtre `render_block` ne remplace donc pas toute réflexion sur le HTML produit, mais il évite d'avoir à la répéter pour chaque bloc du site.

## Les pièges à connaître

- Le filtre s'exécute pour **chaque bloc**, y compris les blocs imbriqués : un bloc groupe contenant dix paragraphes déclenche onze passages du filtre.
- Modifier `$contenu` sans vérifier `blockName` peut casser silencieusement des blocs qui n'avaient rien demandé.
- Le filtre ne s'exécute pas dans l'éditeur : il agit uniquement au moment du rendu côté front, via `parse_blocks()` puis `render_block()`.
- Un bloc réutilisable (`core/block`) passe aussi par ce filtre, une fois résolu en blocs concrets.

## Variante : ne cibler qu'une zone du contenu

Il arrive que l'on veuille limiter l'effet du filtre à certains gabarits, par exemple uniquement sur les articles d'un type de contenu précis. On combine alors le filtre avec un test sur le contexte global, en s'appuyant sur `get_post_type()` à l'intérieur de la fonction filtrée :

```
add_filter( 'render_block', function( $contenu, $bloc ) {
    if ( 'core/quote' !== $bloc['blockName'] ) {
        return $contenu;
    }
    if ( 'temoignage' !== get_post_type() ) {
        return $contenu;
    }
    return str_replace( 'wp-block-quote', 'wp-block-quote temoignage-mis-en-avant', $contenu );
}, 10, 2 );
```

Cette variante montre l'intérêt du filtre : composer plusieurs conditions simples plutôt que de dupliquer le rendu d'un bloc pour chaque cas de figure.

## Quand préférer une autre approche

Si le besoin porte sur un bloc précis et non transversal, mieux vaut agir directement sur son `render_callback` ou sur son fichier `save.js` : le filtre `render_block` devient alors une couche de complexité inutile, plus difficile à tracer qu'une modification localisée dans le bloc lui-même. Il existe aussi une variante plus récente et plus fine, `render_block_data`, qui intervient avant le rendu et permet de modifier les attributs et les blocs internes plutôt que le HTML déjà généré ; elle mérite un article à part entière.

> Sur nos projets, nous réservons ce filtre aux besoins réellement transversaux : tracking, accessibilité systématique, habillage commun. Dès qu'une règle ne concerne qu'un seul bloc, on la range directement dans sa définition.

## En résumé

Le filtre `render_block` est l'outil à connaître pour agir sur l'ensemble des blocs affichés d'un site sans réécrire chaque bloc individuellement. Sa force tient à l'accès au tableau du bloc parsé, qui permet de cibler précisément un `blockName` plutôt que de manipuler du HTML à l'aveugle. Utilisé avec discernement, il évite bien des duplications de code sur un site qui compte plusieurs dizaines de blocs différents.