« Le filtre render_block_{$nom_du_bloc} permet d’intervenir sur le rendu d’un type de bloc précis », indique la documentation des hooks de rendu disponible sur developer.wordpress.org. Appliqué au bloc core/template-part, ce mécanisme donne render_block_core/template-part, un point d’intervention précis pour qui veut modifier le rendu final d’une zone de gabarit sans réécrire le fichier entier qui la contient.
Ce billet s’adresse aux développeurs qui veulent modifier le rendu d’une zone de template part sans surcharger tout le fichier concerné. Il n’aborde pas les Fibers de PHP, une fonctionnalité bas niveau sans rapport avec le sujet traité ici.
Différence avec pre_render_block
Contrairement à pre_render_block, qui intercepte le rendu avant qu’il ne soit produit, render_block_core/template-part reçoit le HTML déjà généré par WordPress. L’intervention se fait donc sur un résultat existant, pour l’enrichir ou le modifier, plutôt que pour le remplacer intégralement depuis zéro.
add_filter( 'render_block_core/template-part', function( $contenu, $bloc ) {
if ( 'header' !== ( $bloc['attrs']['slug'] ?? '' ) ) {
return $contenu;
}
$bandeau = '<div class="bandeau-information">Livraison offerte ce mois-ci</div>';
return $bandeau . $contenu;
}, 10, 2 );Un cas d’usage précis
Imaginons un site qui souhaite afficher un bandeau d’information temporaire au-dessus de son en-tête, sans dupliquer le fragment de gabarit existant ni créer une nouvelle variante. Le filtre ci-dessus injecte ce bandeau uniquement lorsque la zone concernée correspond bien à l’en-tête, identifié par son slug.
Cibler précisément la bonne zone
- Le tableau
$bloc['attrs']contient le slug de la zone de template part concernée, indispensable pour ne pas affecter toutes les zones indistinctement. - Une vérification systématique de ce slug évite qu’un bandeau destiné à l’en-tête n’apparaisse également dans le pied de page.
- Le contenu retourné doit rester un fragment HTML valide, cohérent avec ce qu’attend la structure globale du gabarit englobant.
Pourquoi préférer cette approche à une duplication de fichier
Dupliquer un fragment de gabarit pour y ajouter un élément ponctuel présente un inconvénient réel : toute modification future du fragment d’origine doit être répercutée manuellement sur sa copie, ce qui multiplie les risques d’incohérence au fil du temps. Le filtre, lui, s’applique dynamiquement, sans jamais faire diverger deux versions d’un même contenu.
Un contenu dupliqué pour un besoin temporaire devient presque toujours un contenu oublié une fois le besoin passé — un filtre conditionnel, lui, disparaît proprement dès qu’on retire le code qui l’a introduit.
Limiter la portée dans le temps
Pour un besoin ponctuel comme un bandeau promotionnel, il est recommandé de conditionner également le filtre à une plage de dates, plutôt que de compter sur une désactivation manuelle qui risque d’être oubliée :
add_filter( 'render_block_core/template-part', function( $contenu, $bloc ) {
$aujourd_hui = current_time( 'timestamp' );
$fin_operation = strtotime( '2022-10-31 23:59:59' );
if ( 'header' !== ( $bloc['attrs']['slug'] ?? '' ) || $aujourd_hui > $fin_operation ) {
return $contenu;
}
return '<div class="bandeau-information">Livraison offerte ce mois-ci</div>' . $contenu;
}, 10, 2 );En résumé
Le filtre render_block_core/template-part offre un point d’intervention ciblé pour enrichir le rendu déjà généré d’une zone de gabarit précise, sans dupliquer de fichier ni multiplier les variantes. Associé à une vérification de slug et, si nécessaire, à une condition de date, il permet des interventions ponctuelles propres, faciles à retirer une fois leur utilité passée.
