Sur un site d’actualités que j’accompagne, la question du résumé d’article revient sans cesse : faut-il une longueur fixe, faut-il laisser la rédaction couper à la main, faut-il un lien « lire la suite » systématique ? En testant le prototype de boucle de contenu disponible dans les dernières versions du plugin Gutenberg, j’ai découvert que ces questions trouvaient déjà des débuts de réponse via un bloc dédié : Résumé d’article.
Ce bloc s’insère à l’intérieur du gabarit répété de la boucle expérimentale, aux côtés du Titre d’article et de l’Image mise en avant. Son comportement reprend fidèlement celui de la fonction the_excerpt(), avec quelques réglages en plus directement accessibles depuis l’inspecteur.
Le comportement du résumé automatique
Par défaut, le bloc affiche cinquante-cinq mots, la même valeur que la fonction PHP historique utilise via le filtre excerpt_length. Dans l’inspecteur du bloc, un champ numérique permet de modifier cette longueur directement, sans écrire une ligne de code, ce qui est un vrai gain pour une équipe éditoriale autonome.
Le texte tronqué se termine par des points de suspension configurables, équivalent visuel du filtre excerpt_more traditionnellement utilisé en PHP. On peut aussi choisir d’afficher un lien « Lire la suite » séparé, ce qui correspond à l’attribut showMoreOnNewLine exposé par le bloc.
Le respect de la balise more insérée manuellement
Point intéressant : si l’article source contient une balise insérée manuellement par le rédacteur dans l’éditeur classique de blocs, ce bloc Résumé la respecte et affiche le contenu jusqu’à cette balise, plutôt que la troncature automatique par nombre de mots. C’est exactement le comportement qu’offre déjà the_excerpt() côté PHP, reproduit fidèlement dans ce nouveau contexte de blocs.
Sur le projet évoqué plus haut, la rédaction avait pris l’habitude d’insérer cette balise more pour contrôler manuellement la coupure sur les articles les plus travaillés. Migrer vers ce bloc de résumé n’a donc rien cassé dans leurs habitudes, ce qui a grandement facilité l’adoption du prototype pour les tests internes.
Les limites propres à ce stade expérimental
- Ce bloc ne fonctionne que dans le contexte de la boucle expérimentale, il n’a pas de sens isolé dans un article classique.
- Aucun réglage ne permet encore de personnaliser le balisage HTML englobant le résumé, contrairement à ce que permettrait un template de thème classique.
- La compatibilité avec les extensions qui filtrent
get_the_excerpt()côté PHP n’est pas garantie à ce stade, certaines extensions n’étant pas encore adaptées à ce nouveau rendu par blocs.
Pour un site en production, je resterais donc prudent sur ce bloc tant que la boucle qui l’englobe n’est pas stabilisée dans le cœur de WordPress. Mais pour un prototype ou une maquette interactive présentée à un client, l’effet est déjà bluffant de fidélité avec l’existant.
Un test grandeur nature sur une archive
J’ai reproduit l’archive de catégorie du site d’actualités avec ce prototype de boucle, bloc Résumé compris, et comparé visuellement au rendu produit par le thème PHP classique. À l’exception de quelques espacements CSS à ajuster, le résultat était identique, ce qui confirme la maturité technique de ce bloc précis, même si l’ensemble du système qui l’entoure reste jeune.
Un bloc isolé peut déjà être fiable, même quand tout l’échafaudage autour de lui est encore un chantier. C’est ce genre de nuance qu’il faut savoir observer avant de juger un prototype trop sévèrement.
Pour aller plus loin
Je surveille désormais l’apparition d’un bloc équivalent pour le contenu complet de l’article, qui permettrait de composer une archive entièrement par blocs sans distinguer résumé et contenu intégral. Cette évolution, si elle arrive, changerait considérablement la manière de construire des pages de listing.
En attendant, ce bloc Résumé d’article, aussi modeste soit-il en apparence, illustre bien la philosophie du projet : reproduire fidèlement l’existant PHP avant d’ajouter de nouvelles possibilités.
