Un magazine en ligne construisait ses articles entièrement avec l’éditeur de blocs natif : citations, galeries, tableaux, colonnes, blocs personnalisés pour les fiches produits chroniquées. Le premier réflexe côté front avait été de récupérer le contenu rendu en HTML via content { rendered } et de le parser à la main pour retrouver la structure. Fragile, verbeux, et incapable de distinguer proprement un bloc personnalisé d’un simple paragraphe.
WPGraphQL Content Blocks change complètement l’approche : plutôt que de renvoyer du HTML à interpréter, l’extension expose directement l’arbre des blocs de l’éditeur, chacun avec son type GraphQL propre et ses attributs correctement typés.
Ce que l’extension change dans le schéma
Une fois activée, chaque type de contenu qui utilise l’éditeur de blocs gagne un champ editorBlocks, qui renvoie une liste de blocs typés plutôt qu’une chaîne HTML. Un bloc citation natif ressort par exemple sous forme d’un type CoreQuote avec ses propriétés de citation et d’attribution directement accessibles.
{
post(id: "chronique-du-mois", idType: SLUG) {
editorBlocks {
__typename
... on CoreParagraph { content }
... on CoreQuote { value citation }
... on CoreGallery { innerBlocks { ... on CoreImage { url alt } } }
}
}
}
Les blocs personnalisés suivent la même logique
Un bloc personnalisé enregistré côté PHP avec register_block_type et ses attributs déclarés dans son block.json ressort lui aussi comme un type GraphQL dédié, à condition que ses attributs respectent des types simples reconnus par l’extension (chaîne, nombre, booléen). Pour le bloc « fiche produit chroniqué » de ce projet, chaque attribut (nom du produit, note, lien d’achat) est devenu directement interrogeable, sans aucune extraction manuelle depuis un contenu HTML.
Rendre les blocs côté front
Comme pour un champ flexible ACF, on construit un registre qui associe chaque __typename de bloc à un composant front dédié :
const registreBlocs = {
CoreParagraph: BlocParagraphe,
CoreQuote: BlocCitation,
CoreGallery: BlocGalerie,
AcmeFicheProduit: BlocFicheProduit,
};
function ArticleComplet({ blocs }) {
return blocs.map((bloc, i) => {
const Composant = registreBlocs[bloc.__typename];
return Composant ? <Composant key={i} {...bloc} /> : null;
});
}
Les blocs imbriqués (une colonne contenant elle-même des paragraphes, une galerie contenant des images) exposent leurs enfants via un champ innerBlocks, qu’il faut alors traiter récursivement avec le même registre.
Ce qu’on gagne par rapport au HTML brut
- Plus aucune expression régulière pour retrouver un attribut caché dans un commentaire de bloc HTML.
- Un contrôle total sur le rendu de chaque type de bloc côté front, sans dépendre du CSS du thème d’origine.
- Une détection immédiate quand un bloc inconnu apparaît dans le contenu, plutôt qu’un rendu silencieusement incorrect.
Ordonner et filtrer les blocs avant le rendu
Le tableau editorBlocks respecte l’ordre exact de composition dans l’éditeur, ce qui évite tout retri côté front. Une pratique utile sur ce projet a consisté à filtrer, avant le rendu, les blocs purement décoratifs sans équivalent utile côté front (un simple espaceur, par exemple), plutôt que de laisser le registre de composants renvoyer silencieusement null pour chacun d’eux : le filtrage explicite en amont rend le composant de rendu plus lisible pour quiconque reprend le projet plus tard.
Une limite à connaître
Tous les blocs tiers ne déclarent pas proprement leurs attributs dans un block.json conforme, en particulier les blocs plus anciens écrits avant la généralisation de ce format. Dans ce cas, l’extension retombe sur une représentation générique moins exploitable, et il faut parfois réécrire soi-même la déclaration du bloc concerné pour profiter pleinement du typage.
Un bloc personnalisé bien déclaré dès le départ, avec des attributs typés dans son
block.json, s’exporte proprement en GraphQL sans aucun travail supplémentaire : ça vaut la peine de soigner cette déclaration dès la création du bloc.
Ce qu’on retient
WPGraphQL Content Blocks rapproche le front de ce que l’éditeur voit réellement, bloc par bloc, plutôt que d’un rendu HTML à réinterpréter. Pour un site qui exploite largement l’éditeur natif avec des blocs personnalisés, c’est probablement l’approche la plus fidèle et la plus maintenable pour reconstituer la mise en page côté découplé.
