# WP_Block_Editor_Context : ce que l’éditeur transmet réellement à vos composants

> D'où viennent le post en cours ou les capacités disponibles dans un composant d'édition personnalisé ? La réponse tient dans un seul objet PHP transmis aux filtres de réglages.

- Auteur : WordPress Développement
- Publié le : 2021-09-14
- Mis à jour le : 2021-09-14
- Catégorie : Blocs Gutenberg
- URL : https://www.wpmoderne.fr/blocs/wp-block-editor-context-donnees-transmises-composants/

## L’essentiel

- Un objet transmis à get_block_editor_settings et consorts
- Distingue le contexte post, site et widgets
- Sert à conditionner un réglage selon l'écran ouvert

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

> L'essentiel à retenir : Un objet transmis à get_block_editor_settings et consorts ; Distingue le contexte post, site et widgets ; Sert à conditionner un réglage selon l'écran ouvert

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_Context` est 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 (`context` dans `block.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](https://developer.wordpress.org/reference/classes/wp_block_editor_context/).