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
- Importer
addFilterdepuis@wordpress/hooksetcreateHigherOrderComponentdepuis@wordpress/compose. - Écrire un composant d’ordre supérieur qui reçoit le composant original en argument et retourne un composant enrichi.
- Dans ce composant, lire les props transmises (notamment
attributesetname) pour décider si l’habillage doit s’appliquer. - Enregistrer le filtre avec
addFilter( 'editor.BlockListBlock', 'namespace/nom-du-filtre', monComposant ). - 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
);

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.namepour 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.