Depuis l’arrivée de l’éditeur de blocs en 2018, deux mécanismes de rendu coexistent pour un même bloc dynamique, ce qui laisse perplexe quiconque découvre pour la première fois un tutoriel un peu ancien : la fonction JavaScript save() semble définir le rendu final, alors qu’un fichier PHP render_callback vient ensuite le remplacer entièrement. Comprendre pourquoi ces deux mécanismes cohabitent éclaire une bonne partie des vieux tutoriels qui mélangent les deux approches sans toujours l’expliquer.
Le rôle réel de save() pour un bloc dynamique
Pour un bloc statique, save() définit directement le balisage HTML qui sera stocké tel quel dans le contenu de l’article, entre les commentaires de bloc (<!-- wp:mon-bloc -->). Pour un bloc dynamique, en revanche, save() ne sert plus à produire le rendu final affiché aux visiteurs : son rôle se limite à définir ce qui sera sérialisé dans la base de données, souvent réduit à null ou à un balisage minimal servant de secours en cas de désactivation de l’extension qui enregistre le bloc.
Le rôle de render_callback
Lorsqu’un bloc est enregistré côté PHP avec un render_callback (ou, plus récemment, une clé render dans block.json pointant vers un fichier de rendu), cette fonction prend systématiquement le dessus sur le contenu sérialisé par save() au moment d’afficher la page : WordPress ignore le balisage stocké et exécute la fonction PHP à chaque affichage, en lui passant les attributs désérialisés du bloc. C’est ce mécanisme qui permet à un bloc d’afficher une donnée toujours à jour (une liste d’articles récents, une météo, un compteur) plutôt qu’un instantané figé au moment de la rédaction.
Pourquoi ne pas avoir supprimé save() pour ces blocs
Trois raisons expliquent le maintien de save() même pour un bloc entièrement dynamique. D’abord, le format de sérialisation du contenu WordPress repose sur des commentaires HTML qui encadrent une trace du bloc dans la base ; sans un minimum de balisage, la récupération de secours en cas de désactivation de l’extension deviendrait impossible, laissant un vide silencieux là où le bloc était affiché. Ensuite, les outils tiers qui analysent le contenu (recherche, export, certains plugins de cache) s’appuient parfois sur cette trace HTML minimale pour repérer la présence du bloc, sans exécuter de PHP. Enfin, la validation du contenu par l’éditeur, qui compare le rendu attendu au contenu stocké pour détecter une éventuelle corruption, a besoin d’une référence stable, même minimale, pour les blocs qui en fournissent une.
Le cas des tutoriels anciens
De nombreux tutoriels publiés autour de 2018 et 2019, période où les bonnes pratiques autour des blocs entièrement dynamiques n’étaient pas encore stabilisées, montrent des blocs où save() reproduit une partie significative du rendu, dans l’idée de fournir un affichage minimal même sans PHP actif. Cette pratique a progressivement cédé la place à un usage plus strict de save() réduit à null, à mesure que la communauté a affiné sa compréhension du mécanisme et de ses pièges.
save()retournenull: convention actuelle pour un bloc entièrement dynamique, la plus simple à maintenir.save()retourne un balisage réduit : utile comme filet de sécurité en cas de désactivation de l’extension.save()qui duplique tout le rendu final : pratique héritée des débuts, aujourd’hui source de confusion et de désynchronisation.
Un piège concret de cette cohabitation
Quand save() reproduit une partie du rendu et que render_callback évolue de son côté sans que save() ne soit mis à jour en parallèle, l’aperçu affiché dans l’éditeur (basé sur save() pour un bloc sans ServerSideRender) diverge silencieusement du rendu réel du site. C’est l’une des raisons pour lesquelles un bloc entièrement dynamique gagne à réduire save() au strict minimum et à s’appuyer sur ServerSideRender pour l’aperçu dans l’éditeur, plutôt que de maintenir deux logiques de rendu en parallèle.
En résumé
La cohabitation entre save() et render_callback n’est pas une incohérence de l’éditeur de blocs, mais le reflet d’un besoin de secours et de compatibilité qui existe depuis l’introduction de ce système en 2018. Pour un bloc conçu aujourd’hui, la règle la plus simple reste de réduire save() à sa plus stricte expression et de laisser render_callback, ou la clé render de block.json, porter seul la responsabilité du rendu affiché aux visiteurs.
