Le WordPress d'aujourd'hui, décodé pour les développeurs

Blocs Gutenberg

editor.BlockListBlock enveloppe le rendu de chaque bloc dans l’éditeur

Ajouter un badge, une bordure conditionnelle ou une icône d'alerte autour de chaque bloc dans l'éditeur, sans toucher au code de chaque bloc : le filtre editor.BlockListBlock s'en charge.

Par WordPress Développement • 30 septembre 2026 • 4 min de lecture • Aucun commentaire
editor.BlockListBlock enveloppe le rendu de chaque bloc dans l'éditeur

addFilter( 'editor.BlockListBlock', 'mon-agence/badge-brouillon', habillerBloc ); — cette ligne suffit à intercepter, pour chaque bloc affiché dans le canevas de l’éditeur, le composant qui l’enveloppe visuellement, sans jamais modifier le fichier edit.js propre à chaque type de bloc.

Ce filtre répond à un besoin transversal : ajouter un élément visuel autour de tous les blocs répondant à une condition donnée (un badge « contenu non traduit », une bordure d’alerte sur les blocs contenant une donnée obsolète, une icône de statut éditorial), sans avoir à modifier individuellement chaque type de bloc concerné.

Comprendre ce que BlockListBlock représente

BlockListBlock est le composant interne qui encadre chaque bloc rendu dans la liste des blocs de l’éditeur : il gère la sélection visuelle, les bordures d’interaction et le conteneur qui entoure le rendu propre du bloc. Le filtrer via editor.BlockListBlock, exposé par le système de @wordpress/hooks, permet d’envelopper ce composant dans un composant d’ordre supérieur (higher-order component) qui ajoute un élément visuel avant, après ou autour du rendu original, sans en modifier le contenu interne.

Mise en place pas à pas

  1. Importer addFilter depuis @wordpress/hooks et createHigherOrderComponent depuis @wordpress/compose.
  2. Écrire un composant d’ordre supérieur qui reçoit le composant original en argument et retourne un composant enrichi.
  3. Dans ce composant, lire les props transmises (notamment attributes et name) pour décider si l’habillage doit s’appliquer.
  4. Enregistrer le filtre avec addFilter( 'editor.BlockListBlock', 'namespace/nom-du-filtre', monComposant ).
  5. Vérifier que le filtre ne s’applique qu’aux blocs concernés, pour ne pas alourdir visuellement l’ensemble de l’éditeur.
import { addFilter } from '@wordpress/hooks';
import { createHigherOrderComponent } from '@wordpress/compose';

const ajouterBadgeBrouillon = createHigherOrderComponent( ( BlockListBlock ) => {
	return ( props ) => {
		const estBrouillon = props.attributes?.statutContenu === 'brouillon';

		if ( ! estBrouillon ) {
			return <BlockListBlock { ...props } /></blocklistblock>;
		}

		return (
			<BlockListBlock
				{ ...props }
				className={ ( props.className || '' ) + ' bloc-en-brouillon' }
			/></blocklistblock>
		);
	};
}, 'ajouterBadgeBrouillon' );

addFilter(
	'editor.BlockListBlock',
	'mon-agence/badge-brouillon',
	ajouterBadgeBrouillon
);
L'essentiel à retenir : Enveloppe chaque instance de bloc affichée dans l'éditeur ; S'applique globalement, sans modifier le code de chaque bloc ; N'a aucun effet sur le rendu final côté front

Cibler précisément les bons blocs

Sans condition, le composant d’ordre supérieur s’applique à tous les blocs de l’éditeur, ce qui rend le filtre inutilisable en pratique : chaque bloc recevrait la même classe ou le même badge. La vérification doit porter à la fois sur le nom du bloc (propriété name transmise par BlockListBlock) et, le cas échéant, sur ses attributs, pour ne modifier l’apparence que des instances réellement concernées.

  • Vérifier props.name pour restreindre l’effet à un ou plusieurs types de blocs précis.
  • Vérifier les attributs pertinents pour une condition plus fine (statut, état, valeur particulière).
  • Toujours retourner le composant original inchangé dans le cas par défaut, pour ne jamais casser le rendu des autres blocs.

Ce filtre ne concerne que l’éditeur

Un point à ne jamais perdre de vue : editor.BlockListBlock agit exclusivement sur le rendu affiché dans l’interface d’édition. Il n’a strictement aucun effet sur le balisage servi aux visiteurs du site, qui continue de suivre uniquement save() ou render_callback. C’est précisément ce qui le rend adapté à des indicateurs éditoriaux (statut de relecture, alerte de contenu obsolète) qui n’ont aucune raison d’apparaître côté front.

Un piège de performance à surveiller

Comme ce filtre s’exécute pour chaque bloc de chaque page ouverte dans l’éditeur, une logique de vérification coûteuse placée à l’intérieur (un appel réseau, un calcul lourd) peut ralentir sensiblement l’ensemble de l’éditeur, bloc par bloc. Les conditions vérifiées dans ce filtre doivent rester des lectures simples d’attributs ou de propriétés déjà disponibles, jamais des opérations asynchrones.

En résumé

editor.BlockListBlock permet d’ajouter un habillage visuel transversal à l’éditeur, indépendamment du code propre à chaque bloc, à condition de bien cibler les blocs concernés et de garder la logique de condition légère. Pour tout indicateur purement éditorial, sans équivalent nécessaire côté front, c’est l’un des filtres les plus directs pour enrichir l’expérience de rédaction sans toucher au code métier de chaque bloc.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Partager :

À propos de l'auteur

WordPress Développement

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi