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
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
$contenusans vérifierblockNamepeut 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()puisrender_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.
