# PluginSidebar et registerPlugin : un panneau global à l’éditeur
> Pas envie de créer un bloc juste pour ajouter un outil à l'éditeur ? PluginSidebar permet d'accrocher un panneau entier avec sa propre icône dans la barre d'outils.
- Auteur : Clément Hadrot
- Publié le : 2020-03-16
- Mis à jour le : 2020-03-16
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/pluginsidebar-registerplugin-panneau-editeur/
## L’essentiel
- registerPlugin déclare le point d'entrée du plugin
- PluginSidebar ajoute une icône dédiée dans la barre
- PluginSidebarMoreMenuItem duplique l'accès dans le menu
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 = () => (
<>
{ __( 'Statut de publication', 'mon-agence' ) }
);
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`.
> L'essentiel à retenir : registerPlugin déclare le point d'entrée du plugin ; PluginSidebar ajoute une icône dédiée dans la barre ; PluginSidebarMoreMenuItem duplique l'accès dans le menu
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 `PanelBody` peut être replié par défaut via la prop `initialOpen={ false }`.
- Plusieurs `PanelBody` peuvent cohabiter dans un même `PluginSidebar` pour organiser l'information par thème.
- Le composant `PluginSidebarMoreMenuItem` n'a de sens que combiné à un `PluginSidebar` du 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.