Faut-il vraiment écrire du JavaScript pour afficher une fiche de bien immobilier dans l’éditeur de blocs ? Sur un projet pour une agence immobilière indépendante qui avait besoin d’une dizaine de blocs différents (fiche bien, carte des annonces, formulaire d’estimation, avis clients), la question méritait d’être posée sérieusement avant de se lancer dans un développement entièrement fait main.
Ce billet compare l’extension Meta Box Blocks, qui génère des blocs à partir de champs personnalisés sans écrire de JavaScript, à un bloc natif développé entièrement à la main. ACF Blocks, solution voisine déjà comparée ailleurs dans ce blog, n’est pas repris ici.
Comment fonctionne Meta Box Blocks
Meta Box Blocks s’appuie sur le système de champs personnalisés de l’extension Meta Box, déjà répandue sur de nombreux projets pour gérer des champs avancés. Chaque groupe de champs peut être transformé en bloc Gutenberg, avec un gabarit d’affichage écrit en PHP classique, sans toucher à l’API JavaScript des blocs.
[
'id' => 'fiche-bien',
'title' => 'Fiche bien immobilier',
'fields' => array(
array( 'id' => 'prix', 'name' => 'Prix', 'type' => 'number' ),
array( 'id' => 'surface', 'name' => 'Surface', 'type' => 'number' ),
),
'render_callback' => 'afficher_fiche_bien',
]Le même bloc, écrit à la main
La version fait main du même bloc exige une déclaration JavaScript complète, un composant d’édition, une déclaration d’attributs, et un rendu PHP séparé côté serveur, soit plusieurs fichiers à maintenir pour un seul bloc :
registerBlockType( 'agence/fiche-bien', {
attributes: {
prix: { type: 'number', default: 0 },
surface: { type: 'number', default: 0 },
},
edit: Editer,
save: () => null,
} );
Le tableau comparatif
| Critère | Meta Box Blocks | Bloc fait main |
|---|---|---|
| Temps pour un premier bloc simple | Environ 2 heures | Environ 2 jours |
| Connaissances JavaScript requises | Aucune | Indispensables |
| Souplesse d’interaction dans l’éditeur | Limitée aux champs proposés | Totale |
| Dépendance à une extension tierce | Oui, permanente | Aucune |
| Coût de maintenance à long terme | Faible par bloc | Plus élevé mais mieux maîtrisé |
Ce que Meta Box Blocks ne permet pas facilement
- Une interaction complexe dans l’éditeur, comme un glisser-déposer de photos réordonnables
- Un aperçu en direct qui diffère sensiblement du rendu final côté front
- Une logique conditionnelle avancée entre plusieurs champs affichés dans l’éditeur
Le gabarit d’affichage, côté rendu
Le gabarit associé au bloc reste un simple fichier PHP, appelé par le render_callback déclaré plus haut, avec accès direct aux valeurs des champs via les fonctions de l’extension :
function afficher_fiche_bien( $attributs, $contenu, $bloc ) {
$post_id = get_the_ID();
$prix = rwmb_meta( 'prix', array(), $post_id );
$surface = rwmb_meta( 'surface', array(), $post_id );
printf(
'<article><p>%s €</p><p>%s m²</p></article>',
esc_html( $prix ),
esc_html( $surface )
);
}Cette approche reste lisible même pour un développeur qui découvre le projet, puisqu’elle ne mobilise aucune notion propre à l’API JavaScript des blocs : un simple appel de fonction PHP suffit à retrouver la valeur d’un champ, exactement comme sur un champ personnalisé classique affiché dans un gabarit de thème.
Le critère de décision qui a vraiment tranché
Pour l’agence immobilière, le nombre de blocs à produire (une dizaine) a fait pencher la balance vers Meta Box Blocks : le gain de temps cumulé sur dix blocs dépassait largement la souplesse perdue sur chacun d’entre eux, aucun des blocs demandés ne nécessitant d’interaction complexe dans l’éditeur. Un unique bloc très spécifique, avec une interaction poussée, aurait justifié l’inverse.
Le critère qui compte vraiment n’est pas la complexité d’un bloc pris isolément, mais le nombre de blocs à produire sur l’ensemble du projet : ce calcul change souvent la décision.
Notre verdict
Meta Box Blocks convient très bien à un projet qui doit produire plusieurs blocs d’affichage de champs sans interaction complexe, avec un gain de temps réel et mesurable. Un bloc fait main reste préférable dès qu’une interaction fine dans l’éditeur devient centrale au besoin, ou quand la dépendance à une extension tierce n’est pas souhaitée sur le long terme.
