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' ],
] );
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_restEn 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.
