add_theme_support( 'editor-styles' ); : cette seule ligne, ajoutée dans functions.php, ouvre la porte à un éditeur de blocs qui ressemble enfin au rendu public du site, plutôt qu’à une page blanche générique avec une police par défaut. Sur un thème classique doté d’une typographie et d’une largeur de contenu spécifiques, cet écart entre l’éditeur et le rendu final complique le travail des rédacteurs, qui ajustent des blocs à l’aveugle avant de découvrir le résultat réel en prévisualisation.
La correction ne nécessite ni extension tierce ni thème bloc : quatre étapes, réalisables en une session de travail, suffisent à aligner visuellement l’éditeur sur le rendu final d’un thème classique.
Étape 1 : déclarer le support de l’éditeur
La première étape active la fonctionnalité elle-même, sans laquelle aucune feuille de style personnalisée ne sera chargée dans l’éditeur :
<?php
// functions.php
add_action( 'after_setup_theme', function () {
add_theme_support( 'editor-styles' );
} );
Sans cette déclaration, toute tentative d’ajouter une feuille de style dédiée à l’éditeur reste sans effet : WordPress ignore l’appel suivant tant que ce support n’est pas explicitement activé.
Étape 2 : indiquer le fichier CSS à charger dans l’éditeur
La fonction add_editor_style() précise le chemin du fichier CSS que l’éditeur doit charger, en plus de ses propres styles internes :
<?php
add_action( 'after_setup_theme', function () {
add_theme_support( 'editor-styles' );
add_editor_style( 'assets/css/editor-style.css' );
} );
Ce fichier peut être partagé avec la feuille de style publique du thème, ou constituer un fichier distinct qui n’importe que les règles utiles à la zone d’édition : typographie, couleurs de texte, largeurs de blocs.

Étape 3 : reprendre la largeur de contenu réelle, pas une valeur arbitraire
L’erreur la plus fréquente à cette étape consiste à fixer une largeur de contenu dans editor-style.css sans vérifier qu’elle correspond à la largeur réellement appliquée en façade du site. Si le thème limite la zone de texte à 720 pixels via une classe .entry-content, la feuille de l’éditeur doit reproduire cette même contrainte sur la zone d’écriture :
.editor-styles-wrapper .entry-content,
.editor-styles-wrapper .wp-block-post-content {
max-width: 720px;
margin-left: auto;
margin-right: auto;
font-family: 'Source Sans Pro', sans-serif;
font-size: 1.05rem;
line-height: 1.6;
}
Cette correspondance exacte entre largeur d’éditeur et largeur de rendu final est ce qui évite au rédacteur de composer des paragraphes qui paraîtront trop courts ou trop longs une fois publiés.
Étape 4 : gérer les alignements larges et pleine largeur si le thème les supporte
Si le thème déclare également le support des alignements larges via add_theme_support( 'align-wide' ), la feuille d’éditeur doit prévoir les classes correspondantes, faute de quoi une image alignée en pleine largeur dans l’éditeur apparaîtra à la même largeur que le texte courant, sans donner d’aperçu fidèle :
.alignwidedoit reprendre la largeur intermédiaire définie côté public..alignfulldoit s’étendre visuellement jusqu’aux bords de la zone d’édition.- Un contrôle visuel, bloc par bloc, reste nécessaire après ce réglage : certains thèmes appliquent ces largeurs via des règles plus complexes qu’un simple
max-width.
Vérifier le résultat
Une fois les quatre étapes en place, l’ouverture de l’éditeur sur un article existant doit montrer une typographie, une largeur de texte et des alignements cohérents avec la prévisualisation publique. Un écart persistant, le plus souvent, provient d’une règle CSS publique trop spécifique, portée par un sélecteur que la feuille d’éditeur ne reproduit pas à l’identique.
Un éditeur fidèle au rendu final n’est pas un luxe esthétique : c’est ce qui évite au rédacteur de corriger, après publication, des choix de mise en forme qu’il pensait déjà corrects à l’écran.
Pour aller plus loin
Cette même logique s’étend à d’autres réglages utiles pour un thème classique soigné : la prise en charge des couleurs personnalisées via add_theme_support( 'editor-color-palette', … ), ou celle des tailles de police via add_theme_support( 'editor-font-sizes', … ), qui rapprochent encore un peu plus l’expérience de rédaction du résultat final, sans nécessiter de migration vers un thème bloc.