D’où un composant personnalisé de l’éditeur de blocs sait-il si l’on modifie un article, une page du site ou une zone de widgets ? La réponse ne se trouve pas côté JavaScript, mais dans une classe PHP introduite avec WordPress 5.8 : WP_Block_Editor_Context. Elle circule dans plusieurs filtres liés aux réglages de l’éditeur, et c’est elle qui détermine, en amont, ce qui sera finalement exposé à React.
Avant cette classe, distinguer un contexte d’édition d’un autre imposait souvent des vérifications approximatives, basées sur l’écran courant ou sur des constantes globales peu fiables. WP_Block_Editor_Context apporte un objet unique et prévisible, transmis systématiquement au bon moment.
Où apparaît cet objet
Le filtre get_block_editor_settings( $settings, $context ) reçoit en second argument une instance de WP_Block_Editor_Context. C’est également le cas du filtre block_editor_rest_api_preload_paths, utilisé pour précharger des requêtes REST avant l’ouverture de l’éditeur. Dans les deux cas, l’objet expose une propriété post lorsqu’on édite un article classique, ou reste vide lorsqu’on se trouve dans l’éditeur de site.
Ce sont ces deux points d’entrée qui permettent d’adapter des réglages transmis à l’éditeur : ajouter une donnée dans $settings uniquement pour un type de contenu précis, ou retirer un chemin de préchargement inutile hors du contexte concerné.
La propriété post et son absence
La propriété la plus utile au quotidien reste $context->post. Lorsqu’elle est renseignée, elle contient l’objet WP_Post de l’article en cours d’édition, ce qui permet de lire son type de contenu, son statut ou ses métadonnées existantes avant de décider quoi transmettre à l’éditeur.
add_filter( 'get_block_editor_settings', function( $settings, $context ) {
if ( ! $context->post ) {
return $settings; // éditeur de site, pas d'article associé
}
if ( 'fiche-produit' === $context->post->post_type ) {
$settings['fournisseurDefaut'] = get_option( 'fournisseur_par_defaut' );
}
return $settings;
}, 10, 2 );
Quand l’éditeur de site (FSE) est ouvert, sans article associé, cette propriété reste vide. C’est le signal le plus fiable pour distinguer les deux contextes, bien plus robuste qu’un test sur l’URL de l’écran d’administration.
Les capacités disponibles selon le contexte
Un second usage fréquent consiste à vérifier les capacités de l’utilisateur avant d’exposer un réglage sensible. L’objet WP_Block_Editor_Context ne porte pas directement les capacités, mais son couplage avec current_user_can() à l’intérieur du même filtre permet de composer une logique fine :
add_filter( 'get_block_editor_settings', function( $settings, $context ) {
if ( $context->post && current_user_can( 'edit_others_posts' ) ) {
$settings['optionsAvancees'] = true;
}
return $settings;
}, 10, 2 );
Cette combinaison évite de transmettre un réglage avancé à un profil de rédacteur qui n’en a pas l’usage, sans dupliquer la vérification côté JavaScript où elle serait moins fiable.
Un contexte transmis, pas construit par vos soins
WP_Block_Editor_Contextest instanciée par le cœur de WordPress, jamais par un développeur tiers.- Elle porte une seule propriété publique documentée :
post, potentiellement nulle. - Elle circule uniquement dans les filtres liés au chargement de l’éditeur, pas dans le rendu d’un bloc particulier.
- Elle ne doit pas être confondue avec le contexte de blocs (
contextdansblock.json), qui relie un bloc parent à ses blocs enfants côté React.
Une confusion fréquente à éviter
Beaucoup de développeurs cherchent la source du contexte transmis à un composant React personnalisé (une PluginSidebar, par exemple) directement dans cette classe PHP. Or ce composant reçoit ses données via wp.data côté client, en particulier via le magasin core/editor, et non via WP_Block_Editor_Context. Cette dernière agit uniquement en amont, au moment où PHP construit les réglages transmis une fois à l’ouverture de l’éditeur.
Sur nos projets, dès qu’un réglage dépend du type de contenu ou du rôle de l’utilisateur, on préfère résoudre la logique côté PHP via ce contexte plutôt que de la reconstruire en JavaScript à partir de
wp.data, plus lent et plus fragile.
Notre verdict
WP_Block_Editor_Context reste une classe discrète, rarement citée dans les tutoriels grand public, mais indispensable dès qu’un site multiplie les types de contenu et les profils d’utilisateurs. Elle permet de garder les réglages de l’éditeur propres et contextuels, plutôt que d’exposer systématiquement toutes les options à tout le monde. La documentation officielle du projet WordPress référence sa signature exacte sur developer.wordpress.org.
