Chapitre 8.5 — Blocs dynamiques (render PHP)

⏱️ TL;DR — Un bloc dynamique ne stocke pas de HTML : son save renvoie null (ou rien), et le HTML front est généré à chaque affichage par du PHP (render.php déclaré dans block.json, ou render_callback). C’est le bon choix dès que le rendu dépend de données qui évoluent (un livre, des articles récents, un prix, l’utilisateur courant) — cela évite l’invalidation des blocs statiques et garde le contenu toujours à jour. Le edit reste en React ; seul le rendu front passe côté serveur.

🎯 Objectifs

• Distinguer bloc statique et dynamique (rappel + décision).
• Créer un bloc dynamique (render.php + save null).
• Recevoir attributs, contenu et contexte dans le PHP de rendu.
• Sécuriser le rendu (échappement, ch. 7.7).

1. Statique vs dynamique : la décision

Règle : contenu rédactionnel figé → statique ; contenu issu de données (une entité, une requête, l’état du site) → dynamique.

2. Déclarer le rendu PHP

Dans block.json, on pointe un fichier de rendu :

{
  "name": "wpr/livre-une",
  "attributes": { "livreId": { "type": "number" }, "afficherPrix": { "type": "boolean", "default": true } },
  "render": "file:./render.php"
}

Et save renvoie null (le bloc n’écrit pas de HTML) :

// src/save.js
export default function save() {
    return null; // rendu géré par le serveur
}

3. Le fichier render.php

WordPress exécute render.php à chaque affichage, en exposant $attributes, $content (les InnerBlocks rendus, ch. 8.6) et $block (l’objet bloc) :

<?php
// render.php — $attributes, $content, $block disponibles
$livre_id = isset( $attributes['livreId'] ) ? absint( $attributes['livreId'] ) : 0;
if ( ! $livre_id ) {
    return; // rien à afficher
}
$titre = get_the_title( $livre_id );
$prix  = get_post_meta( $livre_id, 'wpr_prix', true );
$url   = get_permalink( $livre_id );
 
// useBlockProps() côté serveur : applique classes/aligns/supports
$wrapper = get_block_wrapper_attributes( array( 'class' => 'wpr-livre-une' ) );
?>
<div <?php echo $wrapper; // déjà échappé par le cœur ?>>
    <a href="<?php echo esc_url( $url ); ?>">
        <?php echo esc_html( $titre ); ?>
    </a>
    <?php if ( ! empty( $attributes['afficherPrix'] ) && $prix ) : ?>
        <span class="prix"><?php echo esc_html( number_format_i18n( (float) $prix, 2 ) ); ?> €</span>
    <?php endif; ?>
</div>

Deux points clés :

• get_block_wrapper_attributes() est l’équivalent PHP de useBlockProps() : il applique les classes/alignements/supports sur l’élément racine. À utiliser pour que les réglages natifs (couleur, alignement) fonctionnent sur le front.
• Échapper toutes les sorties (esc_html, esc_url — ch. 7.7) : le rendu PHP est du code serveur, la sécurité s’applique pleinement.

⚠️ Piège — oublier get_block_wrapper_attributes(). Sans lui, les supports (couleur de fond, alignement wide/full, espacement) déclarés dans block.json ne s’appliquent pas sur le front (les classes générées ne sont pas posées). C’est le pendant serveur de « oublier useBlockProps ».

4. Alternative : render_callback en PHP

Sans render.php, on peut enregistrer le bloc avec un callback :

register_block_type( __DIR__ . '/build', array(
    'render_callback' => 'wpr_livre_une_render',
) );
 
function wpr_livre_une_render( $attributes, $content, $block ) {
    // même logique, retourne une chaîne HTML
    return '…';
}

render.php (déclaré dans block.json) est la voie moderne et recommandée ; render_callback reste utile pour brancher une classe/méthode existante.

5. Un aperçu correct dans l’éditeur

Le edit (React) doit refléter le rendu, mais il tourne dans l’éditeur : pour afficher les données du livre choisi, il récupère ces données via @wordpress/data/api-fetch (ch. 8.7), ou via le composant ServerSideRender qui demande au serveur de rendre le bloc et l’affiche tel quel :

import ServerSideRender from '@wordpress/server-side-render';
 
<ServerSideRender block="wpr/livre-une" attributes={ attributes } />

ServerSideRender garantit un aperçu identique au front (pratique), au prix d’un appel serveur à chaque changement. Pour une UX plus fluide, on reconstruit souvent l’aperçu en React à partir des données récupérées (ch. 8.7).

💡 Pour un dev React — Un bloc dynamique, c’est SSR par bloc : le edit est votre composant client (éditeur), le render.php est le rendu serveur (comme un Server Component qui lit la base à la requête). ServerSideRender ≈ demander au serveur le HTML et l’injecter — pratique mais moins fluide qu’un rendu client à partir de données. Le pattern « éditeur = React, front = serveur » vous est familier ; ici il est explicite et séparé.

✏️ Exercices

1. Un bloc affiche « les 3 derniers articles ». Statique ou dynamique ? Justifiez.
2. Quel est l’équivalent PHP de useBlockProps() et pourquoi est-il important ?
3. Quelles sont les variables disponibles dans render.php ?

🧠 Quiz de révision

Chapitre suivant : InnerBlocks & composition.