Une agence qui gérait la maintenance d’un site à forte fréquentation voulait donner à ses rédacteurs un accès rapide à un tableau de bord de statut de publication : nombre de mots, dernière modification par un autre auteur, alertes SEO basiques. Rien de tout cela ne concernait un article en particulier ni un bloc précis : c’était une information transversale, qui devait être disponible partout dans l’éditeur, pas seulement dans la colonne de réglages d’un document.
C’est exactement le cas d’usage de PluginSidebar, un composant du package @wordpress/edit-post qui permet d’enregistrer un panneau global accessible depuis sa propre icône dans la barre d’outils supérieure de l’éditeur, indépendamment de tout bloc sélectionné. Contrairement à PluginDocumentSettingPanel, qui s’insère dans la colonne native aux côtés de l’extrait ou des catégories, PluginSidebar vit dans son propre espace, avec sa propre icône visible en permanence.
Le point d’entrée avec registerPlugin
Tout commence par registerPlugin, importé depuis @wordpress/plugins, qui déclare un nom unique pour le plugin d’édition et associe un composant React à son rendu. C’est la porte d’entrée générique utilisée par tous les types d’extensions à l’éditeur, qu’il s’agisse d’un panneau, d’une barre d’outils personnalisée ou d’un simple effet de bord.
import { registerPlugin } from '@wordpress/plugins';
import { PluginSidebar, PluginSidebarMoreMenuItem } from '@wordpress/edit-post';
import { PanelBody, TextControl } from '@wordpress/components';
import { __ } from '@wordpress/i18n';
import { wordcount } from './icons';
const StatusPanel = () => (
<>
<PluginSidebarMoreMenuItem target="statut-panel" icon={wordcount}>
{ __( 'Statut de publication', 'mon-agence' ) }
</PluginSidebarMoreMenuItem>
<PluginSidebar name="statut-panel" icon={wordcount} title={ __( 'Statut de publication', 'mon-agence' ) }>
<PanelBody>
<TextControl label={ __( 'Note interne', 'mon-agence' ) } />
</PanelBody>
</PluginSidebar>
</>
);
registerPlugin( 'statut-de-publication', { render: StatusPanel, icon: wordcount } );
Pourquoi deux composants pour un seul panneau
PluginSidebar affiche l’icône directement dans la barre d’outils, mais l’espace y est limité : au-delà de quelques extensions actives, WordPress regroupe automatiquement les icônes surnuméraires dans le menu représenté par les trois points verticaux. C’est là qu’intervient PluginSidebarMoreMenuItem, qui ajoute une entrée textuelle dans ce même menu, pointant vers le panneau grâce à la prop target partagée avec le nom donné au PluginSidebar.

Sans cette entrée dans le menu, un panneau enregistré uniquement via PluginSidebar reste accessible tant qu’il tient dans la barre d’outils, mais devient introuvable dès qu’un thème ou une extension tierce ajoute suffisamment d’autres icônes pour le faire disparaître de l’affichage visible.
Charger le script au bon moment
Le script du plugin doit être enregistré côté PHP avec une dépendance explicite sur wp-edit-post, sans quoi les composants importés ne seront tout simplement pas disponibles :
function mon_agence_enregistrer_plugin_editeur() {
wp_enqueue_script(
'mon-agence-statut-panel',
plugins_url( 'build/index.js', __FILE__ ),
array( 'wp-plugins', 'wp-edit-post', 'wp-element', 'wp-components', 'wp-i18n' ),
filemtime( plugin_dir_path( __FILE__ ) . 'build/index.js' )
);
}
add_action( 'enqueue_block_editor_assets', 'mon_agence_enregistrer_plugin_editeur' );
L’action enqueue_block_editor_assets est celle qui garantit que le script est chargé uniquement dans le contexte de l’éditeur, sans polluer le front du site avec du JavaScript qui n’a aucune raison d’y être exécuté.
Alimenter le panneau avec des données réelles
Un panneau vide n’a que peu d’intérêt : dans le cas de l’agence évoquée plus haut, le compteur de mots était calculé à partir du contenu de l’article via useSelect sur le store core/editor, en lisant l’attribut content de l’entité en cours d’édition. Le principe reste simple : un composant fonctionnel classique, alimenté par les stores de données de l’éditeur, affiché à l’intérieur d’un PanelBody pour bénéficier du style natif à onglets repliables.
- Un
PanelBodypeut être replié par défaut via la propinitialOpen={ false }. - Plusieurs
PanelBodypeuvent cohabiter dans un mêmePluginSidebarpour organiser l’information par thème. - Le composant
PluginSidebarMoreMenuItemn’a de sens que combiné à unPluginSidebardu même nom, jamais seul.
Une icône qui mérite un vrai soin
L’icône passée en prop mérite une attention particulière : contrairement à un simple import depuis @wordpress/icons, un projet d’agence a souvent intérêt à définir ses propres icônes SVG au format attendu par les composants Dashicon ou par un composant SVG du package @wordpress/primitives, afin de garder une cohérence visuelle avec l’identité du client plutôt qu’avec le set d’icônes générique de WordPress.
En résumé
PluginSidebar et registerPlugin forment un couple minimal mais complet pour étendre l’éditeur sans passer par la création d’un bloc supplémentaire. La combinaison avec PluginSidebarMoreMenuItem garantit que le panneau reste accessible même quand la barre d’outils se sature d’icônes concurrentes, un détail que beaucoup de développeurs découvrent seulement une fois leur extension installée aux côtés d’une dizaine d’autres sur un site client.