Un client vendait des biens immobiliers, chaque fiche étant un article personnalisé enrichi de champs ACF : surface, nombre de pièces, prix, ville. La question posée était simple en apparence : comment afficher ces champs directement dans un gabarit de l’éditeur de site expérimental, sans revenir à un fichier PHP classique et sans attendre une hypothétique fonctionnalité native encore absente du plugin Gutenberg à ce stade ?
Après plusieurs essais, la solution la plus stable est restée, sans grande surprise, le bon vieux shortcode, couplé à un bloc de rendu générique. Ce n’est pas la solution la plus élégante qu’on imagine pour l’avenir, mais c’est celle qui fonctionne aujourd’hui sans complexité excessive.
La méthode retenue : shortcode et bloc Shortcode
Advanced Custom Fields fournit depuis longtemps une fonction get_field() pour récupérer la valeur d’un champ personnalisé associé à l’article courant. En l’enveloppant dans un shortcode maison, ce champ devient utilisable partout où un shortcode est accepté, y compris dans un gabarit de l’éditeur de site via le bloc natif core/shortcode.
add_shortcode( 'acf_champ', function( $atts ) {
$atts = shortcode_atts( array( 'nom' => '' ), $atts );
if ( empty( $atts['nom'] ) ) {
return '';
}
$valeur = get_field( $atts['nom'] );
return $valeur ? esc_html( $valeur ) : '';
} );Dans le gabarit single du type de contenu « bien immobilier », j’ai inséré un bloc Shortcode avec le contenu [acf_champ nom="surface"] m², répété pour chaque champ à afficher. Le rendu apparaît correctement dans l’éditeur de site, avec toutefois un inconvénient notable : aucune prévisualisation en direct dans l’inspecteur, seulement au moment de l’affichage final de la page.
Pourquoi ne pas écrire un vrai bloc dynamique ACF
ACF propose depuis un moment la possibilité de créer des blocs dynamiques via la fonction acf_register_block_type(), avec un rendu géré par un fichier de template PHP dédié. Cette solution est objectivement plus propre, mais elle demande un temps de développement que le budget de ce projet ne prévoyait pas pour un simple affichage de champs texte et numériques.
Le shortcode, bien que moins noble sur le plan architectural, a permis de livrer une solution fonctionnelle en une heure de travail, alors qu’un bloc dynamique complet aurait demandé une demi-journée supplémentaire pour un gain fonctionnel minime sur ce cas précis.
Ce qui manque encore pour une vraie intégration native
- Aucune liaison déclarative entre un attribut de bloc natif et un champ ACF n’existe à ce stade dans le plugin Gutenberg.
- Chaque champ affiché via shortcode perd la richesse de type que propose ACF, comme le formatage automatique des champs de type Image ou Relation.
- La maintenance repose entièrement sur la cohérence entre le nom du champ déclaré dans ACF et celui utilisé dans le shortcode, sans vérification automatique.
Cette dernière limite m’a d’ailleurs valu une petite frayeur : un champ renommé par erreur dans ACF a silencieusement cassé l’affichage sur une dizaine de fiches, sans message d’erreur visible. J’ai depuis ajouté une vérification systématique du nom de champ avant tout renommage sur ce type de projet.
Ce que j’attends pour la suite
Une vraie liaison native entre un champ de données personnalisé et un attribut de bloc simplifierait énormément ce genre de cas, en évitant le détour par un shortcode qui reste, quoi qu’on en dise, une rustine plutôt qu’une solution pérenne.
Le shortcode n’est pas une honte technique, c’est un outil solide depuis des années. Le vrai risque est de l’utiliser sans documenter pourquoi on l’a choisi plutôt qu’une alternative plus moderne.
Notre verdict
Pour ce projet précis, le shortcode couplé au bloc générique a rempli son rôle sans complication excessive. Je recommande cette approche pour tout affichage simple de champ texte ou numérique, en réservant les blocs dynamiques ACF aux cas où une vraie richesse d’édition visuelle est attendue par le client.
