Le nouvel éditeur de WordPress est dans le coeur depuis la version 5.0. C’est une avancée majeure dans l’évolution de WordPress, dans la façon dont on va concevoir et rédiger notre contenu, mais c’est aussi une petite révolution pour les concepteurs de thèmes.
On a beaucoup de nouvelles fonctionnalités et blocs disponibles, ça c’est cool. Mais en tant que développeur, il faut coder le support pour toutes ces fonctionnalités !
L’objectif de cet article n’est pas de montrer dans le détail comment intégrer votre thème avec l’éditeur, mais de fournir une vue d’ensemble de ce qu’apporte le nouvel éditeur ainsi que du travail à effectuer pour que tout soit parfait, aussi bien sur le devant du site qu’en backend.
Mais bon, rien n’est jamais parfait !
Les blocs sur le devant du site
Gutenberg fonctionne par blocs. Bloc paragraphe, bloc image, bloc média+texte, etc… C’est cool, ça permet de structurer notre contenu et chaque bloc a ses propres fonctionnalités, donc c’est très simple d’ajouter notre contenu et de régler son affichage et ses options comme on le souhaite.
Mais ces blocs génèrent chacun un balisage HTML qui leur est propre sur le front, avec leurs propres classes CSS. Là où l’éditeur classique WYSIWYG insérait une bête balise <img>
, nous avons ceci :
<figure class="wp-block-image">
<img src="..." ... />
<figcaption>...</figcaption>
</figure>
Et ça, c’est pour une simple image sans alignement. Si on ajoute un alignement, le balisage change :
<div class="wp-block-image">
<figure class="aligncenter">
<img src="..." ... />
<figcaption>...</figcaption>
</figure>
</div>
Voilà un bloc bouton:
<div class="wp-block-button">
<a class="wp-block-button__link"> ...</a>
</div>
Et un autre bouton aligné à droite.
<div class="wp-block-button align-right">
<a class="wp-block-button__link"> ...</a>
</div>
Le bouton n’est pas un <button>
, mais un lien avec une classe, ce qui est compréhensible, mais le lien est dans une <div>
. Aussi, si on compare avec le bloc image, la classe .alignright
n’est pas située au même niveau dans l’HTML du bloc. Cela peut poser souci ou pas, mais il faut être prudent. Le balisage peut varier énormément d’un bloc à l’autre, et pour un même bloc, d’un réglage à l’autre.
Dans votre feuille de styles, cela signifie que simplement inclure des styles pour les classes .alignleft
, .alignright
et .aligncenter
n’est plus suffisant. Il y aura probablement des cas particuliers et styles descendants à prévoir selon les blocs.
Le temps où il suffisait de styler les éléments HTML simples parce que c’est ce que l’éditeur de contenu générait en front est révolu ! En plus de fournir des styles pour les éléments HTML simples, Il faudra aussi styler TOUS les blocs du nouvel éditeur et TOUTES les variations de chaque bloc.
Des styles par défaut sont disponibles et vous pouvez vous en servir comme point de départ. Mais vous pouvez aussi redéfinir tous les styles pour tous les blocs, selon vos ambitions. Ayez juste conscience que tous les blocs doivent s’afficher correctement, surtout si vous comptez publier votre thème sur le répertoire officiel, ou le distribuer de quelque autre manière.
Attention aussi aux mises à jour de WordPress. Le nouvel éditeur est encore en mutation, de nouveaux blocs peuvent apparaître, et certains peuvent encore bouger (peu probable, mais bon…)!
Les blocs dans l’éditeur
Un des objectifs de ce nouvel éditeur est d’améliorer l’expérience de création de contenu. Un moyen de rendre la création de contenu plus intuitive et prévisible est de faire en sorte que le contenu de l’éditeur soit le plus proche possible du rendu sur le devant du site. Cela va éviter les multiples allers-retours front/back et fluidifier l’expérience.
Cela signifie que le développeur de thème va devoir fournir aussi des styles pour l’éditeur les plus proches possible des styles du devant du site.
Mais pas question de copier-coller style.css
dans editor-style.css
. Ce serait trop simple ! L’éditeur a un balisage bien plus touffu et parfois, il faudra creuser un peu pour trouver le bon sélecteur.
Heureusement, quand notre feuille de style est chargée, les styles sont préfixés d’un .editor-styles-wrapper
, donc si vous stylez un élément HTML simple comme <h3>
, les styles ne s’appliqueront qu’aux titres dans le contenu de l’éditeur.
La largeur de l’éditeur doit aussi correspondre à la largeur de votre zone de contenu en front autant que possible. Cela permettra d’avoir un meilleur rendu pour les blocs galerie et colonnes par exemple.
L’intégration du thème dans l’éditeur
Votre thème a probablement sa propre palette de couleur, son système de taille de typographie, un dark mode, et plein d’autres trucs cool, non ?
Pour que vos utilisateurs puissent utiliser les couleurs du thème dans leur contenu, Il faut rendre toutes ces options disponibles dans l’éditeur. Ce n’est pas très compliqué, il faut juste quelques lignes de plus dans le fichier functions.php
.
Mais il faut ajouter les styles pour ces options dans vos feuilles de styles, aussi bien front que back ! Par exemple, si vous déclarez des couleurs dans l’éditeur, et que vous ajoutez une de ces couleurs en background d’un paragraphe, de nouvelles classes CSS sont générées.
Ce paragraphe a une couleur d’arrière fond et une couleur de texte. il a les classes has-text-color
, has-background
, has-lightest-grey-color
, has-dark-grey-background-color
. Il faut donc ajouter des styles pour ces classes, en front et en backend.
Le même principe est valable pour les tailles de texte. Vous pouvez déclarer les tailles de texte disponibles pour les blocs permettant choisir la taille du texte. Ce sont juste quelques classes CSS, mais elles doivent être présentes sur le devant du site et dans l’éditeur.
Conclusion
Vous l’aurez compris, intégrer un thème avec le nouvel éditeur n’est pas forcément simple. Ce nouvel éditeur est excellent, mais donne bien plus de travail aux développeurs de thèmes, même si l’on décide de charger les styles par défaut de Gutenberg.
Entre le support pour les alignements grand et pleine largeur, les couleurs du thèmes, la largeur de l’éditeur, les styles de tous les blocs en front ET back, etc… Il y a de quoi faire.
Dans un prochain article, nous verrons comment faire concrètement pour ajouter le support pour le nouvel éditeur dans votre thème, pas de panique ! Pour être notifié, inscrivez-vous simplement à la newsletter plus bas !
Bon, ce thème a encore des petits soucis. Je m’en suis rendu compte en rédigeant cet article ! Donc, je vais aller mettre à jour mes styles de ce pas ! 😉
PS: Je vais bien plus en détails dans mon guide WPCookBook. Vous y apprendrez comment déclarer le support pour Gutenberg dans vos thèmes ainsi que pleins d’autres recettes utiles pour développer vos thèmes et extensions proprement, comme comment créer des réglages dans l’outil de personnalisation, par exemple. Si vous avez aimé ce article et êtes intéressé pour apprendre à développer pour WordPress en utilisant les meilleures pratiques, jetez-y oeil !