Quiz 4 — Blocs React & headless

Vrai. L’éditeur de blocs est une app React : chaque bloc est un composant avec des props (les réglages de l’inspecteur) et des enfants (InnerBlocks).

C’est le manifeste du bloc : nom, attributes, supports, scripts/styles, render (pour les dynamiques). L’équivalent d’un package.json de bloc.

edit = le composant React affiché dans l’éditeur ; save = ce qui est sérialisé dans le contenu. Pour un bloc dynamique, save renvoie null.

save renvoie null et le HTML est produit par un render_callback PHP (déclaré dans block.json) → la donnée reste fraîche côté serveur.

À afficher les réglages du bloc dans la sidebar (panneau de droite) : un portail React vers l’inspecteur, avec des PanelBody, SelectControl, etc.

À lire des données du store (ex. la liste des livres via le store core) dans l’éditeur, de façon réactive. Le hook de lecture du data layer de Gutenberg.

Il scaffolde un bloc conforme (block.json, edit/save, build via @wordpress/scripts). Le point de départ officiel d’un bloc custom.

Parce que l’API contourne l’UI : sans lui (ou avec __return_true par réflexe), c’est une faille. Même en lecture publique, on l’écrit explicitement.

En ouvrant /wp-json/ (racine → namespaces) puis /wp-json/wp/v2/posts, /wp/v2/{cpt}, etc. C’est un contrat de données auto-décrit.

Dans les en-têtes X-WP-Total et X-WP-TotalPages (pas dans le corps JSON). Piège classique du front headless.

À authentifier une machine (script, front Next.js) via l’API sans livrer le vrai mot de passe. Utilisé en Basic Auth, côté serveur uniquement.

WordPress = back-office + source de données (REST/GraphQL) ; Next.js = front rapide qui la consomme (SSG/ISR) et se revalide. WordPress ne reçoit aucun trafic visiteur.

Il pré-génère les routes au build (SSG) — ex. une page par livre — servies en statique, ultra-rapides.

La revalidation incrémentale : fetch(url, { next: { revalidate: 60 } }) régénère la page en arrière-plan au plus toutes les 60 s. Un contenu publié finit par apparaître, sans rebuild complet.

Via le Draft Mode de Next.js : une route signée bascule en rendu dynamique et fetch les brouillons (auth par Application Password). L’éditeur voit son brouillon sans publier.

Par revalidation à la demande : un webhook save_post → une route /api/revalidate (protégée par secret) → revalidatePath(). Plus frais que l’ISR temporel.

REST : natif, simple, cacheable par URL. WPGraphQL : une requête, champs précis, imbrication (moins d’aller-retours). GraphQL pour un front riche.

Si le front et WordPress sont sur des domaines différents et que le fetch est côté navigateur. En headless bien fait, on fetch côté serveur → pas de CORS.

En variables d’environnement, lues côté serveur uniquement (jamais dans le bundle client). Vérifiable dans l’onglet réseau.

À ajouter un champ calculé/formaté à la réponse REST d’un type (get_callback) — ex. exposer prix sur /wp/v2/wpr_book pour le front headless.