Comment utiliser l’éditeur classique dans WordPress : installation, configuration et quand cela a vraiment du sens

L’éditeur classique WordPress est un éditeur de contenu WYSIWYG basé sur TinyMCE qui précède le système de blocs Gutenberg introduit dans WordPress 5.0. Il présente un canevas d’édition unique et linéaire — visuellement similaire à Microsoft Word — où le texte, les médias et le HTML coexistent dans un champ continu plutôt qu’en blocs discrets et empilables. Pour les utilisateurs qui ont besoin de l’installer aujourd’hui, la réponse courte est : installez le plugin Classic Editor officiel depuis le dépôt de plugins WordPress, activez-le et configurez l’éditeur par défaut sous Réglages > Écriture.

Cette réponse en deux phrases couvre la question principale. Le reste de ce guide couvre les différences architecturales entre les deux éditeurs, les raisons techniques légitimes de choisir l’un plutôt que l’autre, les cas particuliers de configuration, et les scénarios où forcer l’éditeur classique crée en réalité plus de problèmes qu’il n’en résout.

Éditeur classique vs. éditeur de blocs Gutenberg : une comparaison technique

Avant de toucher aux paramètres, il est utile de comprendre ce entre quoi vous basculez réellement. La décision n’est pas purement cosmétique.

La différence la plus significative sur le plan opérationnel est le stockage du contenu. L’éditeur classique enregistre du HTML propre. Gutenberg enveloppe chaque unité de contenu dans des annotations de commentaires HTML qui servent de délimiteurs de blocs. Si vous migrez un jour du contenu entre systèmes — vers un CMS headless, un générateur de sites statiques ou une plateforme non-WordPress — la sortie de l’éditeur classique est bien plus facile à analyser et à porter. La grammaire de blocs de Gutenberg est propriétaire au parseur de WordPress.

Pourquoi les développeurs et les propriétaires de sites choisissent encore l’éditeur classique

Compatibilité avec les plugins et thèmes hérités

De nombreux plugins commerciaux — notamment les anciens constructeurs de formulaires, les extensions e-commerce et les plugins de types de publications personnalisés — enregistrent des méta-boîtes qui injectent des champs directement dans l’écran d’édition des articles. Dans Gutenberg, ces méta-boîtes sont reléguées dans un panneau latéral rétractable rendu dans un shim de compatibilité iframe. Ce shim ne se comporte pas toujours correctement : des conflits JavaScript surviennent, la logique conditionnelle se brise, et certains frameworks d’interface de méta-boîtes (les dialogues jQuery UI, par exemple) ne s’initialisent pas correctement dans le contexte de document imbriqué.

Si votre site repose sur des plugins qui utilisent add_meta_box() avec des interfaces utilisateur complexes dépendant de JavaScript, l’éditeur classique élimine entièrement cette catégorie de problèmes.

Restrictions de l’API REST

L’éditeur Gutenberg effectue des requêtes en arrière-plan continues vers l’API REST WordPress — pour récupérer les modèles de blocs, sauvegarder automatiquement les brouillons, récupérer le statut de verrouillage des articles et valider les capacités des utilisateurs. Dans les environnements serveur renforcés où l’API REST est intentionnellement restreinte (via add_filter('rest_authentication_errors', ...) ou des règles au niveau du serveur bloquant /wp-json/), Gutenberg échouera partiellement ou complètement à se charger. L’éditeur classique n’a pas une telle dépendance et fonctionnera normalement sous ces contraintes.

Contrôle de l’éditeur par rôle et sur Multisite

Sur les installations WordPress Multisite, les administrateurs réseau ont parfois besoin d’imposer une expérience d’édition cohérente sur tous les sous-sites — notamment lorsque des éditeurs non techniques sont impliqués. Le plugin Classic Editor prend en charge une option Settings > Writing pour interdire le changement d’éditeur par utilisateur, verrouillant tous les utilisateurs dans l’éditeur classique quelle que soit leur préférence individuelle. Gutenberg n’offre aucun mécanisme d’application équivalent au niveau du réseau sans code personnalisé.

Vitesse de travail pour les contenus à forte densité textuelle

Pour les éditeurs produisant de grands volumes de contenu textuel — articles d’actualité, documentation, documents juridiques — le modèle à canevas unique de l’éditeur classique est réellement plus rapide. Il n’est pas nécessaire d’insérer un nouveau bloc, de sélectionner un type de bloc ou de naviguer entre les panneaux de paramètres de blocs. Vous appuyez sur Entrée et continuez à écrire. Pour les éditeurs qui travaillent au clavier et utilisent les raccourcis de l’onglet HTML, cela compte.

Comment installer le plugin Classic Editor

L’éditeur classique n’est pas inclus dans le cœur de WordPress. Il est maintenu en tant que plugin officiel par l’équipe des contributeurs WordPress et est disponible depuis le dépôt de plugins WordPress.org.

Méthode 1 : Installation via le tableau de bord WordPress

1. Connectez-vous à votre panneau d’administration WordPress (/wp-admin).
2. Accédez à Extensions > Ajouter une extension.
3. Dans le champ de recherche, tapez Classic Editor.
4. Localisez le plugin créé par WordPress Contributors — vérifiez l’auteur, car il existe des plugins imitateurs avec des noms similaires.
5. Cliquez sur Installer maintenant, puis sur Activer.

Méthode 2 : Installation via WP-CLI

Si vous gérez WordPress depuis la ligne de commande — ce qui est une pratique standard sur tout environnement d’hébergement VPS — WP-CLI est nettement plus rapide que l’interface du tableau de bord :

wp plugin install classic-editor --activate

Pour l’installer à l’échelle du réseau sur une installation Multisite :

wp plugin install classic-editor --activate-network

Méthode 3 : Téléchargement manuel

Téléchargez le fichier ZIP du plugin depuis wordpress.org/plugins/classic-editor, puis téléversez-le via Extensions > Ajouter une extension > Téléverser une extension, ou extrayez-le directement sur votre serveur :

cd /var/www/html/wp-content/plugins/
unzip classic-editor.zip

Après extraction, activez via WP-CLI ou le tableau de bord.

Configuration des paramètres de l’éditeur classique

Une fois activé, le plugin expose deux options de configuration sous Réglages > Écriture.

Éditeur par défaut pour tous les utilisateurs

La première option définit la valeur par défaut à l’échelle du site. Vous pouvez choisir entre l’éditeur classique et l’éditeur de blocs. Définir cette option sur l’éditeur classique signifie que chaque nouvel article et chaque nouvelle page s’ouvre dans TinyMCE par défaut.

Autoriser les utilisateurs à changer d’éditeur

La deuxième option contrôle si les utilisateurs individuels peuvent remplacer la valeur par défaut du site article par article. Lorsqu’elle est activée, survoler un article dans la liste Articles > Tous les articles révèle deux liens d’action : Modifier (s’ouvre dans la valeur par défaut du site) et Modifier (éditeur classique) ou Modifier (éditeur de blocs) selon la valeur par défaut actuelle.

Configuration recommandée pour la plupart des sites hérités :

• Éditeur par défaut : éditeur classique
• Autoriser les utilisateurs à changer : Non

Cela empêche les éditeurs d’ouvrir accidentellement du contenu dans Gutenberg et d’injecter par inadvertance des commentaires de grammaire de blocs dans des articles rédigés dans l’éditeur classique — un mélange qui peut provoquer des anomalies de rendu dans certains thèmes.

Utilisation de l’interface de l’éditeur classique

L’onglet Visuel (mode WYSIWYG)

L’onglet Visuel affiche votre contenu via l’aperçu basé sur iframe de TinyMCE. La barre d’outils fournit :

• Mise en forme du texte : Gras (Ctrl+B), Italique (Ctrl+I), Barré, Souligné
• Styles de paragraphe : Titre 1 à Titre 6, Préformaté, Citation
• Listes : Ordonnées et non ordonnées, avec contrôles d’indentation/désindentation
• Liens : Insérer/modifier des hyperliens avec les attributs cible et titre
• Insertion de médias : Ouvre la médiathèque WordPress pour les images, vidéos, fichiers audio et documents
• Coller depuis Word : Supprime le balisage HTML propriétaire de Microsoft Word lors du collage
• Mode d’écriture sans distraction : Bascule en plein écran qui masque toute l’interface d’administration

La barre d’outils comporte deux rangées. Si vous ne voyez qu’une seule rangée, cliquez sur le bouton Basculer la barre d’outils (la dernière icône de la première rangée) pour afficher la deuxième rangée, qui comprend le sélecteur de style de paragraphe, la couleur du texte, la carte des caractères et annuler/rétablir.

L’onglet Texte (mode HTML brut)

L’onglet Texte expose le HTML brut stocké dans post_content. Ce n’est pas un éditeur de code complet — il manque de coloration syntaxique et de numérotation des lignes — mais il vous donne un accès direct au balisage. Scénarios utiles :

• Insertion d’intégrations <iframe> brutes que TinyMCE supprimerait ou échapperait
• Ajout d’attributs HTML personnalisés que l’interface de l’onglet Visuel n’expose pas
• Débogage des problèmes de rendu causés par le nettoyage automatique des balises de TinyMCE

Comportement critique à comprendre : TinyMCE effectue une désinfection HTML lorsque vous basculez de l’onglet Texte vers l’onglet Visuel. Il fermera les balises non fermées, supprimera certains éléments (comme <script> dans certaines configurations) et normalisera les espaces blancs. Si vous écrivez du HTML brut dans l’onglet Texte, vérifiez toujours qu’il survit à un aller-retour vers Visuel avant de publier.

Les méta-boîtes Extrait, Champs personnalisés et Discussion

Sous le canevas principal de l’éditeur, l’éditeur classique affiche l’ensemble complet des méta-boîtes natives de WordPress dans leur disposition d’origine :

• Extrait : Résumé en texte brut utilisé par les thèmes et les plugins SEO pour les méta-descriptions
• Champs personnalisés : Paires clé-valeur stockées dans wp_postmeta — accessibles directement sans basculer vers un panneau latéral
• Discussion : Paramètres de commentaires et de rétroliens par article
• Identifiant : Champ de slug d’URL modifiable (également dans la boîte Publier)
• Auteur : Réattribuer la paternité d’un article sans naviguer ailleurs

Ces méta-boîtes sont toujours visibles et en pleine largeur dans l’éditeur classique. Dans Gutenberg, elles sont soit cachées dans la barre latérale, soit rendues dans l’iframe de compatibilité — une différence UX significative pour les flux de travail qui reposent fortement sur les champs personnalisés.

Basculer entre les éditeurs par article

Si vous avez activé l’option « Autoriser les utilisateurs à changer », le basculement d’éditeur par article fonctionne comme suit :

Depuis la liste des articles :

1. Accédez à Articles > Tous les articles.
2. Survolez le titre de l’article.
3. Cliquez sur Modifier (éditeur classique) ou Modifier (éditeur de blocs) selon les besoins.

Depuis l’intérieur de l’éditeur :

Dans Gutenberg, un lien indiquant Passer à l’éditeur classique apparaît dans le menu à trois points (en haut à droite). Dans l’éditeur classique, un lien indiquant Passer à l’éditeur de blocs apparaît en haut de l’écran.

Avertissement : Basculer un article rédigé dans Gutenberg vers l’éditeur classique — puis l’enregistrer — préservera les annotations de commentaires de grammaire de blocs dans le HTML brut. Ces commentaires sont inoffensifs pour le rendu en front-end mais apparaîtront comme du texte littéral dans l’onglet Texte de l’éditeur classique, ce qui peut prêter à confusion. Revenir à Gutenberg les analysera correctement à nouveau. Le scénario inverse (contenu de l’éditeur classique ouvert dans Gutenberg) est propre, car Gutenberg enveloppe automatiquement le HTML non reconnu dans un bloc Classique.

Désactiver l’éditeur classique sans le plugin

Si vous souhaitez forcer Gutenberg et empêcher l’utilisation de l’éditeur classique — ou si vous souhaitez désactiver Gutenberg sans installer de plugin — WordPress fournit un hook de filtre :

// In functions.php or a site-specific plugin — disable Gutenberg for all post types
add_filter( 'use_block_editor_for_post', '__return_false' );

Cela produit le même effet que le plugin Classic Editor pour l’édition des articles mais n’affecte pas l’éditeur de site (Full Site Editing). Pour une désactivation complète de Gutenberg incluant FSE :

add_filter( 'use_block_editor_for_post', '__return_false' );
add_filter( 'use_widgets_block_editor', '__return_false' );
remove_theme_support( 'widgets-block-editor' );

Cette approche est préférable dans les environnements où l’installation de plugins supplémentaires est restreinte par politique, ou lorsque vous souhaitez que la logique de désactivation soit versionnée dans votre thème ou plugin plutôt que dépendante de l’état d’activation d’un plugin tiers.

Éditeur classique et environnements d’hébergement WordPress

Le plugin Classic Editor lui-même est léger et n’impose aucune exigence côté serveur significative. Cependant, le contexte plus large de votre environnement d’hébergement affecte l’expérience d’édition de manières qui méritent d’être notées.

Sur les plans d’hébergement mutualisé, le panneau d’administration WordPress peut sembler lent car l’exécution PHP et les requêtes de base de données sont en concurrence avec d’autres locataires sur le même serveur. L’éditeur classique est sensiblement plus léger que Gutenberg dans ce contexte — moins d’appels à l’API REST, pas de surcharge de rendu React, et une charge JavaScript plus petite signifient des chargements de page plus rapides dans l’administration. Si vous êtes sur un plan d’hébergement web mutualisé et trouvez l’éditeur de blocs lent, l’éditeur classique est une optimisation pratique.

Sur un VPS avec cPanel, vous avez un contrôle total sur les limites de mémoire PHP, la configuration OPcache et la mise en cache des requêtes MySQL. Dans cet environnement, les deux éditeurs fonctionnent bien, et le choix devient purement une préférence de flux de travail plutôt qu’une nécessité de performance.

Pour les installations WordPress à fort trafic sur des serveurs dédiés, le choix de l’éditeur n’a pratiquement aucun impact sur les performances en front-end — l’interface d’édition n’est chargée que par les utilisateurs administrateurs authentifiés, et la sortie HTML publiée est ce qui compte pour la vitesse des pages.

Pièges courants et cas particuliers

TinyMCE supprimant du HTML valide : La configuration valid_elements et extended_valid_elements de TinyMCE contrôle quelles balises et attributs HTML sont autorisés dans l’éditeur Visuel. Par défaut, il supprime des balises comme <article>, <section>, <figure> (dans les anciennes configurations), et tous les attributs de données personnalisés. Si votre contenu nécessite ces éléments, vous devez étendre les éléments autorisés de TinyMCE via le filtre tiny_mce_before_init :

add_filter( 'tiny_mce_before_init', function( $init ) {
    $init['extended_valid_elements'] = 'span[*],div[*],section[*],article[*]';
    return $init;
} );

Conflits de sauvegarde automatique : L’éditeur classique utilise l’ancienne fonction JavaScript wp_autosave(), qui envoie des requêtes POST à wp-admin/post.php avec action=autosave. Si votre serveur a une limitation de débit agressive ou une règle WAF bloquant les requêtes POST répétées vers wp-admin, les sauvegardes automatiques échoueront silencieusement. Surveillez les journaux d’erreurs de votre serveur en cas de perte de contenu.

Éditeur classique et thèmes Full Site Editing (FSE) : Si votre thème actif est un thème FSE (qui déclare "blockTemplates": true dans theme.json), l’éditeur classique fonctionnera toujours pour le contenu des articles et des pages, mais l’éditeur de site (/wp-admin/site-editor.php) est entièrement basé sur Gutenberg et n’est pas affecté par le plugin Classic Editor. Vous ne pouvez pas utiliser l’éditeur classique pour modifier les modèles de thèmes FSE.

Comportement lors de la désactivation du plugin : La désactivation du plugin Classic Editor ne convertit pas votre contenu. Les articles rédigés dans l’éditeur classique restent en HTML propre. Les articles rédigés dans Gutenberg conservent leur grammaire de blocs. Gutenberg analysera correctement les deux. Il n’y a aucun risque de perte de données lors de la désactivation du plugin.

Matrice de décision : quel éditeur devriez-vous utiliser ?

Utilisez l’éditeur classique si :

• Votre site utilise des plugins avec des interfaces de méta-boîtes complexes qui se brisent dans la couche de compatibilité de Gutenberg
• Votre serveur restreint l’API REST WordPress
• Vous migrez du contenu vers une plateforme non-WordPress et avez besoin d’un HTML propre et portable
• Votre équipe éditoriale est grande, non technique et formée au flux de travail de l’éditeur classique
• Vous exécutez WordPress sur un environnement d’hébergement mutualisé aux ressources limitées

Utilisez Gutenberg si :

• Vous créez de nouveaux sites sans dépendances de plugins hérités
• Votre thème est basé sur des blocs ou compatible FSE
• Vous avez besoin de blocs réutilisables, de modèles de blocs ou de mises en page complexes multi-colonnes sans constructeur de pages
• Vous créez des blocs personnalisés avec register_block_type() pour des projets clients
• Vous souhaitez exploiter l’éditeur de site pour une personnalisation complète du thème

Utilisez les deux (avec le changement par utilisateur activé) si :

• Vous avez une équipe mixte où certains éditeurs préfèrent l’éditeur classique et d’autres préfèrent Gutenberg
• Vous êtes dans une période de transition pour migrer un site hérité vers une architecture basée sur des blocs
• Différents types d’articles sur votre site ont des exigences de complexité différentes

Liste de contrôle technique pratique

Avant de basculer votre site de production vers l’éditeur classique, vérifiez les points suivants :

• ] Confirmez que la version du plugin Classic Editor est à jour (consultez [wordpress.org/plugins/classic-editor pour la dernière version)
• [ ] Testez les interfaces de méta-boîtes de tous les plugins actifs dans l’éditeur classique sur un environnement de staging avant de déployer en production
• [ ] Vérifiez vos filtres tiny_mce_before_init si vous avez des configurations TinyMCE personnalisées qui pourraient entrer en conflit avec les valeurs par défaut du plugin
• [ ] Décidez de la politique « autoriser le changement » et documentez-la pour votre équipe éditoriale
• [ ] Si vous utilisez WP-CLI, confirmez que le plugin est activé avec wp plugin list --status=active
• [ ] Vérifiez que votre thème ne repose pas sur des styles de blocs spécifiques à Gutenberg (classes CSS wp-block-*) pour le rendu en front-end
• [ ] Sauvegardez votre base de données avant d’effectuer des modifications de changement d’éditeur sur un site avec du contenu Gutenberg existant
• [ ] Si vous êtes sur un réseau Multisite, décidez d’activer à l’échelle du réseau ou par site et appliquez via Settings > Writing au niveau du réseau

Associez votre configuration WordPress à un domaine correctement sécurisé en vous assurant que vos certificats SSL sont valides et se renouvellent automatiquement — le panneau d’administration WordPress transmet des cookies d’authentification qui doivent être protégés par HTTPS quel que soit l’éditeur que vous utilisez.

Pour les équipes gérant des flux de travail éditoriaux incluant des notifications par e-mail, des communications avec les auteurs ou des intégrations de newsletters, une configuration d’hébergement e-mail dédiée garantit que les e-mails transactionnels WordPress (réinitialisations de mot de passe, notifications de commentaires, changements de statut des articles) sont délivrés de manière fiable plutôt que routés via le sendmail par défaut d’un serveur mutualisé.

FAQ

Le plugin Classic Editor affecte-t-il le rendu en front-end ou les performances du site ?

Non. Le plugin Classic Editor modifie uniquement l’interface d’édition côté administration. Il n’a aucun impact sur la façon dont WordPress affiche les pages aux visiteurs. Les performances en front-end sont déterminées par votre thème, la couche de mise en cache et la configuration du serveur — et non par l’éditeur utilisé pour rédiger le contenu.

Le passage de Gutenberg à l’éditeur classique corrompra-t-il mon contenu existant basé sur des blocs ?

Non. Gutenberg stocke les annotations de blocs sous forme de commentaires HTML dans post_content. L’éditeur classique affichera ce HTML brut dans son onglet Texte et tentera de le rendre dans l’onglet Visuel. Le contenu n’est pas supprimé ni corrompu. Si vous enregistrez un article Gutenberg dans l’éditeur classique sans le modifier, les annotations de blocs sont préservées. Si vous modifiez et enregistrez, TinyMCE peut normaliser certains espaces blancs mais ne supprimera pas les annotations de commentaires.

Puis-je utiliser l’éditeur classique pour certains types d’articles et Gutenberg pour d’autres ?

Oui, mais pas via l’interface des paramètres du plugin Classic Editor. Vous devez utiliser le filtre use_block_editor_for_post_type dans le code :

add_filter( 'use_block_editor_for_post_type', function( $use_block_editor, $post_type ) {
    if ( $post_type === 'product' ) {
        return false; // Use Classic Editor for WooCommerce products
    }
    return $use_block_editor;
}, 10, 2 );

Le plugin Classic Editor sera-t-il maintenu de façon permanente ?

WordPress.org s’est engagé à maintenir le plugin Classic Editor avec des mises à jour de sécurité et de compatibilité jusqu’en 2024 au moins, et il continue de recevoir des mises à jour au-delà de cet engagement. Cependant, il ne reçoit aucune nouvelle fonctionnalité — il est en mode maintenance. Pour les nouveaux projets à long terme, Gutenberg est la direction stratégique du cœur de WordPress.

L’éditeur classique fonctionne-t-il avec WooCommerce ?

Oui. L’éditeur de produits de WooCommerce a historiquement été construit sur les méta-boîtes de l’éditeur classique. Les versions récentes de WooCommerce (8.x+) ont introduit un nouvel éditeur de produits basé sur des blocs, mais le formulaire de produit hérité basé sur l’éditeur classique reste disponible et est la valeur par défaut pour la plupart des installations. Le plugin Classic Editor n’interfère pas avec les écrans d’édition de produits de WooCommerce.