Aligner l’éditeur classique sur un thème bloc en pleine transition

Sur un chantier de migration d’un site de 400 pages vers un thème bloc, il était hors de question de tout convertir d’un coup. Le client validait progressivement, page par page, pendant que le reste du contenu continuait à être édité avec Classic Editor, toujours actif pour l’équipe rédactionnelle non formée aux blocs. Résultat : deux systèmes de mise en forme devaient cohabiter sans que les visiteurs ne remarquent de rupture visuelle.

Ce cas de figure est plus fréquent qu’il n’y paraît. Une migration complète vers l’édition par blocs prend rarement moins de plusieurs mois sur un site volumineux, et pendant cette période, l’éditeur classique doit continuer à produire un rendu cohérent avec le nouveau theme.json.

Le problème : deux moteurs de style, une seule apparence attendue

Un thème bloc génère l’essentiel de son CSS à partir de theme.json : couleurs, typographie, espacements. L’éditeur classique, lui, ignore complètement ce fichier côté back-office : il applique le CSS chargé via add_editor_style(), une fonctionnalité bien plus ancienne. Sans intervention, le contenu rédigé en éditeur classique s’affiche correctement en front (le CSS du thème s’applique normalement à la page) mais l’aperçu dans l’admin diverge, ce qui perturbe les rédacteurs qui ne savent plus si leur mise en forme est fidèle.

Le vrai risque n’est donc pas le rendu public, déjà cohérent puisque le même theme.json alimente le CSS frontal quel que soit l’éditeur utilisé pour la saisie. Le risque est la confusion en coulisses, qui pousse les rédacteurs à corriger « à l’œil » des styles qui n’ont pas besoin de l’être.

Générer une feuille d’aperçu cohérente avec theme.json

La solution consiste à générer dynamiquement une feuille de style d’aperçu pour l’éditeur classique, à partir des mêmes valeurs que theme.json, plutôt que de la maintenir à la main dans un fichier statique voué à diverger :

function theme_editor_style_dynamique() {
    $settings = wp_get_global_settings();
    $couleur_texte = $settings['color']['palette']['theme'][0]['color'] ?? '#1e1e1e';

    $css = ".editor-styles-wrapper { color: {$couleur_texte}; }";
    wp_add_inline_style( 'editor-preview-dynamique', $css );
}

function theme_enregistrer_style_editeur_dynamique() {
    add_editor_style();
    wp_register_style( 'editor-preview-dynamique', false );
    add_action( 'admin_enqueue_scripts', 'theme_editor_style_dynamique' );
}
add_action( 'admin_init', 'theme_enregistrer_style_editeur_dynamique' );

Cette approche évite de dupliquer les valeurs de couleur et de typographie dans deux fichiers séparés, l’une des causes principales de divergence visuelle constatée au fil des mois de transition.

Les points de vigilance recensés sur ce chantier

• Les tailles de police définies via theme.json (settings.typography.fontSizes) ne s’appliquent pas automatiquement au menu déroulant de tailles de l’éditeur classique, resté sur son propre jeu de valeurs.
• Les couleurs de fond et de texte doivent être répliquées avec les mêmes classes has-*-color pour que le contenu généré en éditeur classique reste compatible si l’article est un jour converti en blocs.
• Les marges et espacements globaux de theme.json (styles.spacing) ne sont pas lus par l’éditeur classique, qui garde sa propre largeur de zone de saisie.

Documenter la limite plutôt que la masquer

Certaines divergences ne valent pas la peine d’être corrigées pour quelques semaines de transition. Nous avons choisi de documenter clairement, dans une note interne partagée avec l’équipe rédactionnelle, les deux ou trois écarts résiduels tolérés (largeur de zone de saisie légèrement différente, par exemple), plutôt que de développer un correctif coûteux pour un problème temporaire.

Sur une migration progressive, le meilleur code est parfois celui qu’on ne développe pas : documenter un écart mineur coûte moins cher que le corriger, tant que le rendu public reste irréprochable.

Notre verdict

Faire cohabiter éditeur classique et thème bloc pendant une migration est tout à fait viable, à condition d’accepter que l’alignement porte sur l’essentiel — couleurs et typographie principales — et non sur une parité pixel près. La feuille de style d’aperçu générée dynamiquement depuis theme.json reste la mesure la plus rentable : elle élimine la source la plus fréquente de divergence sans effort de maintenance supplémentaire une fois en place.