# Désactiver l’éditeur de blocs pour un seul type de contenu

> Le filtre use_block_editor_for_post_type permet de garder l'éditeur classique pour un type de contenu précis, sans toucher au reste du site.

- Auteur : Clément Hadrot
- Publié le : 2025-07-10
- Mis à jour le : 2025-07-10
- Catégorie : Tips
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tips/desactiver-editeur-blocs-un-seul-type-contenu/

## L’essentiel

- Un filtre ciblé sur un seul type de contenu
- Utile pour des CPT générés par import ou API externe
- Ne nécessite pas l'extension Classic Editor complète

Un client gérait un catalogue de plus de deux mille fiches techniques, importées automatiquement chaque nuit depuis un ERP externe via une tâche planifiée. Ce type de contenu, un CPT nommé `fiche-technique`, n'était jamais modifié manuellement dans l'éditeur : son contenu HTML, généré côté ERP, contenait des structures de tableaux complexes que l'éditeur de blocs découpait et reformatait à chaque ouverture, cassant parfois la mise en forme d'origine.

La solution n'était pas de désactiver l'éditeur de blocs pour tout le site — les articles classiques du blog en avaient besoin — mais uniquement pour ce type de contenu précis, via le filtre `use_block_editor_for_post_type`.

## Le filtre ciblé

Introduit avec l'éditeur de blocs, ce filtre reçoit une valeur booléenne et le nom du type de contenu concerné, ce qui permet de renvoyer `false` uniquement pour les cas voulus :

```
add_filter( 'use_block_editor_for_post_type', function ( $utiliser_blocs, $post_type ) {
    if ( 'fiche-technique' === $post_type ) {
        return false;
    }

    return $utiliser_blocs;
}, 10, 2 );
```

Ce filtre suffit à faire réapparaître l'éditeur classique (TinyMCE) pour ce seul type de contenu, sans dépendre de l'extension Classic Editor, qui reste installable mais impose son choix pour l'ensemble du site sauf configuration avancée.

## Vérifier que le type de contenu le permet

Ce filtre n'a d'effet que si le type de contenu prend en charge l'attribut `show_in_rest`, nécessaire à l'éditeur de blocs pour fonctionner via l'API REST. Un CPT enregistré sans cet attribut utilise déjà l'éditeur classique par défaut, sans qu'aucun filtre ne soit nécessaire :

```
register_post_type( 'fiche-technique', [
    'label'        => __( 'Fiches techniques', 'mon-theme' ),
    'public'       => true,
    'show_in_rest' => true, // Nécessaire pour que l'éditeur de blocs soit même proposé
    'supports'     => [ 'title', 'editor', 'custom-fields' ],
] );
```

> L'essentiel à retenir : Un filtre ciblé sur un seul type de contenu ; Utile pour des CPT générés par import ou API externe ; Ne nécessite pas l'extension Classic Editor complète

## Adapter l'écran d'édition à l'éditeur classique

Une fois revenu à l'éditeur classique pour ce type de contenu, certaines fonctionnalités propres à l'éditeur de blocs disparaissent, notamment la barre latérale des paramètres du document. Il faut alors réintroduire, si nécessaire, les métaboxes classiques pour les champs personnalisés qui s'affichaient auparavant dans la barre latérale de l'éditeur de blocs :

```
add_action( 'add_meta_boxes', function () {
    add_meta_box(
        'reference-erp',
        __( 'Référence ERP', 'mon-theme' ),
        'afficher_metabox_reference_erp',
        'fiche-technique',
        'side'
    );
} );
```

## Cas des imports automatisés

Pour ce genre de contenu généré par import, je désactive en général aussi les révisions, inutiles quand le contenu ne provient jamais d'une saisie manuelle, via un filtre sur `wp_revisions_to_keep` ciblé sur ce type de contenu, ce qui allège la table `wp_posts` à long terme.

- Réduire ou désactiver les révisions pour les contenus générés automatiquement.
- Vérifier que la tâche d'import ne déclenche pas d'e-mails de notification destinés normalement à une publication manuelle.
- Documenter clairement dans l'interface (via un message dans la métabox) que ce contenu ne doit pas être modifié manuellement, au risque d'être écrasé à l'import suivant.

> Revenir à l'éditeur classique n'est pas un aveu d'échec face aux blocs : pour du contenu structuré et généré automatiquement, c'est souvent le choix le plus stable.

## Vérifier l'effet du filtre

Après application, un tour par l'écran de liste du type de contenu concerné confirme que le bouton d'ajout ouvre bien l'éditeur classique. Un test complémentaire avec WP-CLI permet de vérifier que l'enregistrement du type de contenu correspond toujours à l'attendu :

```
wp post-type list --field=name,show_in_rest
```

## En résumé

Le filtre `use_block_editor_for_post_type` permet de faire cohabiter éditeur de blocs et éditeur classique sur un même site, type de contenu par type de contenu. C'est une solution plus fine que l'extension Classic Editor pour les projets où seul un contenu précis, souvent généré automatiquement, a besoin de rester en dehors de l'éditeur de blocs.