WordPress 5.6 vient de sortir ce mois-ci, avec en tête d’affiche la compatibilité PHP 8 et l’arrivée de la fonctionnalité de programmation des changements d’auteur. Pendant ce temps, sur le terrain des blocs, un choix d’architecture revient sans cesse en réunion de cadrage : faut-il stocker le HTML final d’un bloc dans le contenu de l’article, ou le régénérer à chaque affichage ? La réponse tient dans un seul mécanisme : le render_callback.
Cet article explique la différence entre bloc statique et bloc dynamique, montre comment écrire un render_callback propre, et surtout détaille les situations où stocker le HTML en base devient une source de bugs difficiles à détecter des mois après la mise en ligne.
Bloc statique contre bloc dynamique : la différence fondamentale
Un bloc « statique », comme ceux que l’on a construits dans les articles précédents, calcule son HTML de sortie une fois pour toutes dans la fonction save(), côté JavaScript. Ce HTML est ensuite figé dans le contenu de l’article (la colonne post_content en base de données), et c’est ce même HTML qui s’affiche indéfiniment sur le front-end, jusqu’à ce que quelqu’un rouvre l’article dans l’éditeur et le republie.
Un bloc « dynamique » fonctionne différemment : sa fonction save() ne retourne rien (ou juste un squelette minimal contenant les attributs), et c’est une fonction PHP, le render_callback, qui génère le HTML final à chaque affichage de la page, en lisant les attributs stockés dans le bloc.
Pourquoi préférer un rendu dynamique dans certains cas
Le cas d’usage le plus parlant, c’est un bloc « articles récents » qui affiche les trois derniers billets du blog. Si ce bloc était statique, il faudrait rouvrir et republier chaque page qui l’utilise à chaque nouvelle publication pour que la liste se mette à jour — ce qui est tout simplement impraticable. Un bloc dynamique, lui, interroge la base de données à chaque chargement de page et affiche toujours la liste la plus fraîche.
D’autres cas typiques :
- Un bloc qui affiche des données susceptibles de changer sans intervention de l’auteur (météo, cours de bourse, statistiques d’un plugin tiers).
- Un bloc dont le rendu dépend du contexte de la requête : utilisateur connecté ou non, langue active, appareil.
- Un bloc qui doit rester cohérent avec une donnée gérée ailleurs dans WordPress (nombre de commentaires, stock d’un produit WooCommerce).
- Un bloc dont la logique de présentation est complexe et que l’on préfère centraliser en PHP plutôt que dupliquer entre
edit()etsave()en JavaScript.
Écrire un render_callback
Le bloc s’enregistre toujours avec register_block_type(), mais cette fois on fournit un render_callback à la place (ou en complément) de editor_script. Prenons l’exemple d’un bloc « derniers articles ».
<?php
function wpmoderne_register_derniers_articles_block() {
wp_register_script(
'wpmoderne-derniers-articles-block',
plugins_url( 'build/index.js', __FILE__ ),
array( 'wp-blocks', 'wp-element', 'wp-block-editor', 'wp-components' ),
filemtime( plugin_dir_path( __FILE__ ) . 'build/index.js' )
);
register_block_type( 'wpmoderne/derniers-articles', array(
'editor_script' => 'wpmoderne-derniers-articles-block',
'attributes' => array(
'nombre' => array(
'type' => 'number',
'default' => 3,
),
),
'render_callback' => 'wpmoderne_render_derniers_articles',
) );
}
add_action( 'init', 'wpmoderne_register_derniers_articles_block' );
function wpmoderne_render_derniers_articles( $attributes ) {
$nombre = isset( $attributes['nombre'] ) ? absint( $attributes['nombre'] ) : 3;
$articles = get_posts( array(
'posts_per_page' => $nombre,
'post_status' => 'publish',
) );
if ( empty( $articles ) ) {
return '';
}
$sortie = '<ul class="wpmoderne-derniers-articles">';
foreach ( $articles as $article ) {
$sortie .= sprintf(
'<li><a href="%1$s">%2$s</a></li>',
esc_url( get_permalink( $article ) ),
esc_html( get_the_title( $article ) )
);
}
$sortie .= '</ul>';
return $sortie;
}Remarquez qu’il n’y a ici aucun editor_style ni style imposé : rien n’empêche de continuer à charger une feuille CSS classique, dynamique ou statique n’a aucune influence sur la gestion des styles. Notez aussi l’usage systématique d’esc_url() et d’esc_html() : comme ce code s’exécute à chaque chargement de page, toute négligence d’échappement devient une faille XSS potentielle exploitable en continu, contrairement à un bloc statique où le HTML est figé au moment de la publication par un utilisateur de confiance.
Le rôle de save() dans un bloc dynamique
Côté JavaScript, la fonction save() d’un bloc entièrement dynamique retourne simplement null :
save() {
return null;
},WordPress enregistre alors uniquement le commentaire délimiteur du bloc avec ses attributs en JSON, sans aucun balisage HTML associé. C’est le render_callback qui a la responsabilité exclusive de produire l’affichage final. Certains blocs adoptent une position intermédiaire : save() retourne un conteneur minimal (une simple <div> avec une classe), et le render_callback vient y injecter dynamiquement le contenu variable. Ce mélange reste rare mais peut avoir du sens pour préserver un point d’ancrage CSS stable.
Pourquoi éviter de stocker le HTML de rendu en base quand ce n’est pas nécessaire
Le piège le plus sournois d’un bloc statique mal choisi, c’est le HTML qui se fige alors qu’il ne devrait pas. Imaginez un bloc « prochain événement » qui affiche la date et le lieu d’un événement stocké dans un type de contenu personnalisé. Si ce bloc est statique et que l’organisateur change la date de l’événement après coup, chaque page qui affichait déjà cet événement continuera de montrer l’ancienne date jusqu’à republication manuelle — un bug quasiment invisible en recette, mais garanti en production.
Un bloc dynamique élimine structurellement ce risque : comme il n’y a pas de copie figée du HTML, il n’y a rien à désynchroniser. C’est également plus sûr en cas de changement de design : modifier la structure HTML produite par le render_callback s’applique instantanément à toutes les occurrences du bloc sur le site, sans avoir à rouvrir et republier chaque article un par un — ce qui, avec un bloc statique, imposerait de gérer une logique de migration de contenu à chaque évolution du save().
Posez-vous systématiquement la question suivante avant de choisir le mode de rendu : « si cette donnée change demain sans que personne ne rouvre l’article, le site doit-il refléter le changement ? » Si la réponse est oui, le bloc doit être dynamique.
Quand le bloc statique reste le bon choix
Le rendu dynamique n’est pas gratuit : chaque affichage du bloc déclenche une exécution PHP, potentiellement une requête en base de données, ce qui a un coût en performance qu’un bloc statique — simple HTML servi tel quel, voire mis en cache par une extension de cache de page — n’a pas. Pour du contenu purement éditorial (un encadré de citation, une mise en forme de texte, un bouton d’appel à l’action), rien ne justifie de payer ce coût à chaque visite : le bloc statique reste largement préférable.
La bonne pratique consiste donc à réserver render_callback aux blocs dont le contenu dépend réellement d’une donnée externe ou évolutive, et à garder les blocs statiques pour tout ce qui relève de la simple mise en forme du texte saisi par l’auteur.
En résumé
Le choix entre bloc statique et bloc dynamique se résume à une question de fraîcheur de la donnée : si le contenu affiché peut changer indépendamment d’une republication de l’article, un render_callback en PHP garantit que le site reste toujours synchronisé avec la réalité. Dans le cas contraire, le HTML figé d’un bloc statique reste plus performant et plus simple à maintenir. Retenez surtout ceci : un bloc dynamique bien conçu ne stocke jamais de HTML de présentation en base, seulement les attributs nécessaires à sa reconstruction — c’est ce qui le rend robuste dans la durée.
