Gutenberg nous permet d’écrire des contenus plus riches rapidement, mais c’est avant tout une superbe opportunité pour nous les développeurs afin de créer des blocs sur mesure à nos besoins et ceux de nos clients.
Sommaire du cours
L’éditeur de blocs, c’est le nouveau standard de WordPress, avec ou sans vous ! Et cette révolution est en cours : de nombreuses agences ont migré vers le Full Site Editing, ou sont en passe le faire.
Il y a plein d’avantages à cela, que l’on va aborder dans ce cours. Vous êtes encore beaucoup à être dubitatifs, et à juste titre, vu le développement chaotique du projet depuis 2018.
Mais rassurez-vous, tout va bien désormais, l’outil est largement stable, et avec la création de blocs sur mesure, vous ne connaitrez aucune limite technique !
Pourquoi choisir Gutenberg et le FSE ?
Tout d’abord, commençons par les avantages d’opter pour l’éditeur de blocs natifs de WordPress lorsque vous créez vos sites.
Vidéo premium
Cette vidéo est réservée aux détenteurs de l’offre premium.
Envie de nous rejoindre ?
J’ai déjà abordé le sujet dans la formation Full Site Editing, notamment dans le cours dédié aux agence web. Voici en substance mes principaux arguments en faveur de Gutenberg et du Full Site Editing :
Un éditeur visuel temps réel
Tout d’abord, l’éditeur de blocs est très visuel, on voit directement le résultat final, au même titre que les éditeurs concurrents comme Elementor ou Divi. On a atteint le véritable WYSIWYG.
Chaque élément est un bloc indépendant du reste, ce qui permet de modifier plus facilement une partie précise de la page.
L’éditeur fournit tout un tas de blocs de mise en page comme les colonnes, les grilles, les groupes et les rangées.
Je ne vous cache pas qu’il y a un petit temps d’adaptation pour la prise en main, et encore quelques défauts d’expérience utilisateur, mais une fois à l’aise, c’est un vrai plaisir.
Créer des sites plus rapidement
Avec plusieurs années d’expériences en Full Site Editing, je peux annoncer qu’on réalise des sites en moyenne 30% plus rapidement qu’avec un autre constructeur, ou qu’avec l’ancienne technique qui nécessitait l’utilisation des champs ACF.
Ce qui nous permet d’être plus rapide, c’est le conditionnement des styles globaux grâce au theme.json, qui nous permet d’établir une ligne directrice pour respecter à la lettre le Design System.
L’autre concept qui va nous faire gagner un maximum de temps, sur un projet mais également d’un projet à l’autre, c’est la création de compositions réutilisables :
Celles-ci peuvent représenter des éléments d’interface, des sections ou même des pages complètes. Ces compositions sont réalisées via l’éditeur. Il n’y a donc pas besoin de passer du temps à intégrer le HTML et le CSS, même si on peut personnaliser tout cela au besoin.
L’avantage, c’est que les couleurs, espacements et typographies sont notées sous forme de variables CSS. Du coup, chaque composition s’adaptera automatiquement d’un site à un autre.
Ainsi, on évite de réinventer la roue à chaque projet. Sur le long terme, on met en place un catalogue géant de compositions prêtes à l’emploi, ou à défaut faciles à réutiliser.
Une meilleure expérience utilisateur pour vos clients
Le très gros avantage de Gutenberg par rapport à ses concurrents, c’est qu’il a été conçu pour que son interface soit la plus simple et la plus minimale possible. Pas d’options à outrance comme sur Elementor.
Contrairement aux autres constructeurs, on peut définir, via le theme.json, les fonctionnalités que l’on souhaite activer, ou au contraire cacher. Ici par exemple avec le sélecteur de couleurs :
Et ça, c’est vraiment un game changer, dans le sens où vous allez offrir à vos clients uniquement les options qu’il aura besoin.
Impossible dans ce cas qu’il sélectionne une couleur hors charte ! Finis donc les sites « sapin de Noël ».
Technologies plus modernes et plus rapides
Gutenberg a entièrement été réalisé en React JS, ce qui change de nos habitudes. La plupart des développeurs WordPress connaissent surtout le PHP.
Du coup, la transition n’est pas forcément évidente, même si en général, c’est beaucoup plus simple que ce qui n’y parait.
Par contre, ça va nous donner plusieurs avantages : tout est fait en temps réel, de manière fluide et sans délai, et surtout, Il n’y a plus de rechargement de page à l’enregistrement, ce qui était un gros point faible de l’ancien éditeur, dans le passé.
Un éditeur natif et extensible
Et enfin toutes ces technologies sont natives et intégrées dans WordPress. Il n’y a donc pas besoin d’installer d’extensions tierces qui vont alourdir les performances et l’interface utilisateur.
De plus, WordPress fournit une API complète pour venir interagir avec cet éditeur : on peut ajouter des menus de partout, déclarer de nouveaux blocs, de nouvelles catégories de blocs… bref, personnaliser au maximum l’expérience utilisateur.
Pourquoi développer ses blocs sur mesure ?
Créer des blocs sur mesure, c’est s’assurer la capacité de repousser les limites techniques de WordPress. Concrètement, vous pouvez absolument TOUT faire avec des blocs.
Vidéo premium
Cette vidéo est réservée aux détenteurs de l’offre premium.
Envie de nous rejoindre ?
Et c’est justement ça leur but : isoler une fonctionnalité attendue, et la réaliser sous forme d’un bloc qu’on pourrait intégrer de partout dans le contenu ou dans le site.
De cette manière, on ne réfléchit plus le site comme un monolithe, mais comme une somme de composants agiles et maléables.
Quelques exemples : un système de filtre, un formulaire, un slider d’articles, un sommaire automatiquement généré, afficher une extension :
SEOPress – On-site SEO & Analytics
SEOPress, une extension SEO simple, rapide, puissante et complète pour WordPress. Améliorez votre classement dans les moteurs de recherche, entièrement en marque blanche. Et maintenant avec l‘IA.
Par exemple, ce bloc s’occupe d’aller chercher automatiquement les informations de l’extension sur WordPress.org, et je le vois s’afficher en temps réel lorsque j’édite mon cours.
Enfin, un bloc est agnostique du site sur lequel il est installé. Cela veut dire que vous allez pouvoir l’installer très facilement sur d’autres sites par la suite.
Comme pour les compositions, vous allez vous composer au fur et à mesure une bibliothèque de blocs en tous genres pour répondre aux besoins de vos clients.
Et plus vous en aurez, plus vous gagnerez du temps sur les prochains projets !
Blocs ACF vs blocs natifs
La question qui revient souvent, c’est celle-ci : vaut-il mieux créer ses blocs avec ACF ou en React, nativement ?
Vidéo premium
Cette vidéo est réservée aux détenteurs de l’offre premium.
Envie de nous rejoindre ?
La question est légitime car votre choix aura potentiellement des grosses implications sur votre méthodologie de travail.
Dans la formation dédiée à ACF, j’ai justement écrit un cours sur la création de blocs Gutenberg via ACF en PHP.
ACF, l’approche classique en PHP
Et la première chose que l’on peut voir, c’est que c’est facile : il suffit de déclarer un groupe de champs, de l’assigner à un bloc, et de déclarer un block.json.
Ensuite, le rendu du bloc est fait exclusivement en PHP, que ce soit en front ou en back. Pour cela, vous utilisez les fonctions classiques de ACF, comme the_field().
C’est donc plus simple pour un développeur PHP qui n’a jamais fait de JS.
Par contre, le rendu n’est pas temps réel : contrairement aux blocs natifs, lorsque vous cliquez sur un bloc ACF, il se transforme en un groupe de champs classique :
Dès que vous quittez le champ, l’aperçu se regénère quasiment immédiatement. Cela dit, ACF a annoncé l’arrivée du inline editing, qui vise à rapprocher l’UX de celle native.
Au final, on peut presque tout faire avec les blocs ACF. Il y a toutefois quelques exceptions : vous ne pourrez pas réaliser un bloc Sommaire auto-généré en temps réel car vous n’aurez pas accès.
Avantages des blocs et champs d’options natifs
Dans les prochains cours je vous présenterais la création de blocs natifs : vous verrez à quel point c’est plus simple que ce que l’on imagine.
Grâce aux blocs natifs, les paramètres seront mieux intégrés dans l’interface de l’éditeur.
D’ailleurs, on a accès à de nombreux champs offerts par WordPress, dont on découvrira un bon nombre dans les prochains chapitres :
Par exemple, le sélecteur de couleurs natif nous confère un bel avantage, car on va pouvoir le contraindre pour afficher uniquement les couleurs de la charte graphique !
Ce que le sélecteur de couleurs d’ACF ne permet pas nativement.
Observez les options de ce bloc (que l’on abordera plus tard) dans la colonne de droite :
Ils sont beaucoup plus élégants, modernes et mieux intégrés que les champs « classiques » de ACF !
Quant au code JS des blocs natifs, ce n’est pas si terrible que ce que l’on peut imaginer :
Alors oui, les syntaxes sont différentes, le templating aussi, mais c’est loin d’être illisible. Dans cet exemple, je gère à la fois l’affichage du bloc dans l’éditeur, ainsi que ses différentes options grâce à des composants natifs comme ToggleControl et RangeControl.
La différence avec ACF, c’est qu’au lieu de configurer un groupe de champs pour mes options, j’invoque directement mes composants d’options dans le code. Ce qui est une approche bien plus appréciée pour un développeur.
Car au final, c’est bien souvent long de configurer des champs dans ACF :
Ne réinventons pas la roue avec le natif !
Dernier avantage majeur pour les blocs natifs, c’est que vous allez pouvoir activer pas mal d’options sans code grâce aux supports !
En effet, les « supports » permettent d’activer le choix des couleurs de texte, de fond, les espacements et la typographie du bloc (entre autres) d’une simple déclaration dans la propriété supports du fichier block.json :
Autant de fonctionnalités qu’on n’aura pas besoin de réinventer à chaque fois !
Bon par contre, il y a quand même un désavantage avec les blocs natifs : il va falloir écrire 2 fois le bloc.
- Sa version interactive dans l’éditeur, avec ses champs d’édition de contenu et de personnalisation des paramètres, via
edit.js; - Et sa version HTML à enregistrer en base de données, via
save.js.
On peut l’observer sur la capture de mon IDE :
Du coup, ça donne parfois un peu plus de boulot, mais c’est le seul moyen pour obtenir une telle interactivité.
Alors, blocs ACF en PHP ou blocs natifs en JS ?
Maintenant que vous avez tous les éléments en tête, voici les questions que vous devez vous poser afin de peser les pour et les contre :
- Est-ce que j’ai l’envie et le temps de me former sur JS et React ?
- Est-ce que je veux une expérience utilisateur vraiment parfaite ?
- Est-ce que je vais avoir besoin de faire des blocs avancés ?
Si les réponses sont oui, optez pour les blocs natifs !
Demandez-vous aussi :
- Est-ce que je veux gagner du temps et en rentabilité ?
- Est-ce que l’UX proposée par ACF me suffit ?
- Est-ce que mes besoins en blocs restent classiques ?
Dans ce cas, vous pourriez opter pour les blocs ACF.
Mais avant de vous faire une idée définitive, je vous conseille cela dit d’avancer dans la formation. En plus, les premiers cours sont gratuits !
En tous cas, vous l’avez compris, j’ai une nette préférence pour les blocs natifs, maintenant que je les maîtrise parfaitement, mais pour vous, la question se pose encore !
Aujourd’hui, je suis 100% conquis par Gutenberg, alors que j’étais sceptique lors de mon premier essai. Aujourd’hui je ne reviendrais pas en arrière. Je peux me concentrer sur l’écriture « riche » sans frustration, et cela change tout.
Je peux également proposer des blocs personnalisés faits sur-mesure à mes clients pour améliorer leur propre expérience de rédaction.
Des clients satisfaits, une meilleure productivité de vos équipes, bref, tout ce qui est bon pour votre business.
0
Questions, réponses et commentaires