Quand une donnée change en dehors du contrôle du rédacteur, comme la disponibilité d’un article en stock ou la liste des commentaires récents, ce n’est jamais au moment de l’écriture qu’il faut calculer le résultat, mais au moment précis où un visiteur charge la page. C’est le principe du rendu côté serveur : au lieu de sauvegarder un HTML figé dans l’article, le bloc laisse cette tâche à une fonction PHP exécutée à chaque requête, qui a accès à l’état réel de la base de données à cet instant.
Fonctionnement dans WordPress
Cette fonction s’enregistre via l’argument render_callback de register_block_type(), ou, plus couramment aujourd’hui, via un fichier référencé par la clé render de block.json. Elle reçoit en paramètres les attributs du bloc, le contenu déjà rendu de ses éventuels blocs internes, et une instance de WP_Block donnant accès au contexte courant, puis retourne une chaîne de HTML qui remplace entièrement ce qui aurait été sauvegardé par une fonction save.
Exemple
function rendre_derniers_articles( $attributs ) {
$articles = get_posts( [ 'numberposts' => $attributs['nombre'] ?? 3 ] );
$sortie = '<ul>';
foreach ( $articles as $article ) {
$sortie .= '<li>' . esc_html( $article->post_title ) . '</li>';
}
return $sortie . '</ul>';
}Bon à savoir
- Un rendu côté serveur mal optimisé, avec des requêtes lourdes exécutées à chaque chargement, peut ralentir sensiblement une page à fort trafic : la mise en cache d’objet ou de fragment devient alors utile.
- Il ne faut pas confondre ce mécanisme avec le rendu React côté serveur (SSR) utilisé dans certains frameworks JavaScript : dans WordPress, il s’agit exclusivement de PHP exécuté sur le serveur d’hébergement.