Gutenberg

Développement de blocs Gutenberg

L’éditeur de blocs est la meilleure chose arrivée au travail éditorial dans WordPress, et la plus facile à rater. Bien fait, les rédacteurs assemblent des pages à partir de composants qui portent déjà la bonne structure, le bon balisage et le bon comportement d’accessibilité. Mal fait, il devient un constructeur de pages aux mille réglages et un site différent sur chaque page. Le développement de blocs Gutenberg sur mesure, c’est le travail de bâtir ce jeu de composants : chaque bloc enregistre ses réglages sous forme de données structurées et produit son balisage depuis PHP au moment où la page est demandée, au lieu d’enregistrer du HTML dans la base de données.

  • Blocs rendus côté serveur : le balisage vient de PHP à l’affichage, pas du HTML enregistré
  • Un jeu de composants choisi, pas une toile ouverte
  • Structure et accessibilité imposées par le bloc plutôt que documentées dans un guide
  • Panneaux et outillage éditoriaux là où le flux de travail en a besoin
Parler de votre projet
Approche

Un système de composants, pas un constructeur de pages

La question de conception derrière une bibliothèque de blocs est celle du degré de liberté. Trop peu et les rédacteurs ne peuvent pas bâtir les pages dont ils ont besoin, alors ils demandent un développeur ou collent du HTML. Trop et chaque réglage devient une façon de produire quelque chose hors marque, inaccessible ou illisible sur téléphone, et après deux ans le système de design n’existe plus que dans les maquettes d’origine.

Nous construisons des blocs étroits et composables : une primitive de mise en page, un petit ensemble de composants de contenu, et des options limitées aux choix qu’un designer a réellement approuvés. Les rédacteurs obtiennent une vraie liberté sur la disposition des composants et très peu sur leur apparence, ce qui est le partage qui garde un grand site cohérent.

Nous les construisons rendus côté serveur : le bloc enregistre ses attributs, et le balisage est produit en PHP au moment de l’affichage. Cela coûte un peu plus au départ et cela signifie que le balisage de tout le site peut changer en un seul endroit : une correction de structure de titres, un ajustement d’accessibilité ou un nouveau jeton de design s’applique à toutes les pages existantes sans qu’un rédacteur touche à quoi que ce soit et sans migration de base de données.

Primitives de mise en page

Un petit ensemble de blocs de section, de grille et de cellule qui portent les règles d’espacement et de conteneur, pour que chaque page retombe sur le même rythme sans que les rédacteurs choisissent des valeurs de marge.

Composants de contenu

Titres, cartes, éléments de service et de fonctionnalité, galeries, appels à l’action, accordéons de FAQ avec leurs données structurées, chacun produisant par construction un balisage correct et accessible.

Blocs dynamiques

Des blocs qui interrogent le contenu ou appellent une intégration à l’affichage : grilles de projets, répertoires, listes filtrées, données en direct. Configurés par les rédacteurs, rendus par le code.

Motifs et gabarits

Des arrangements précomposés pour les types de pages qu’une équipe bâtit à répétition, pour qu’une nouvelle page d’atterrissage parte de quelque chose de correct plutôt que d’un document vide.

Panneaux latéraux d'éditeur

Des panneaux pour les métadonnées et le flux de travail dont un projet a besoin : champs SEO, réglages de publication, données par page et rapports, intégrés à l’éditeur plutôt que rangés dans un écran d’administration distinct.

Contraintes éditoriales

Gabarits verrouillés, règles de blocs autorisés et champs obligatoires là où la structure compte, pour que la bonne forme de page soit la valeur par défaut plutôt qu’une convention dont il faut se souvenir.

Preuves

Des bibliothèques de blocs en production

Quatre bibliothèques livrées, et ce que chacune a changé pour les personnes qui s’en servent. C’est cela qui mérite d’être jugé : un nombre de blocs ne dit rien sur la capacité d’une équipe à faire vivre son site.

Une correction atteint cinq marques

Multi-Prêts, Mortgage Alliance, Invis, Mortgage Intelligence et Intelligence Hypothécaire partagent une bibliothèque tenue dans un thème parent, avec un thème enfant chacune. Corriger un niveau de titre, un état de focus ou la mise en page d’une carte est un seul changement qui atteint les cinq, au lieu de la même retouche faite cinq fois et oubliée la cinquième.

Une boutique menée sans développeur

Sur iAmEvolving®, la fondatrice publie produits, prix, leçons de cours et pages de campagne depuis l’éditeur WordPress, sans constructeur de pages ni extension de commerce en dessous. Le parcours d’achat est assemblé à partir de composants plutôt que configuré dans l’extension de quelqu’un d’autre, donc le modifier n’exige pas d’ouvrir un billet.

Des permissions que le rédacteur ne peut pas rater

Doolittle Lake Club sépare le contenu des membres de celui des actionnaires. Le bouton de téléchargement vérifie qui demande avant de servir un fichier, et les blocs de liste filtrent selon le rôle au moment de l’affichage. Un administrateur bénévole ne peut donc pas publier le mauvais document au mauvais public en choisissant le mauvais bloc.

La page que vous lisez

wplook.ca repose sur la même approche, ce qui en fait la seule affirmation de cette page que vous pouvez vérifier vous-même. Ouvrez le code source : chaque section, carte et accordéon ici a été produit par PHP au moment où vous avez demandé la page, et rien n’est du HTML enregistré dans une base de données.

Démarrer un projet

Vous bâtissez un système éditorial, pas seulement un site?

Dites-nous qui édite le site et ce que ces personnes doivent pouvoir bâtir sans aide. La bibliothèque de blocs se conçoit autour de cette réponse, et c’est la partie d’une construction qui rapporte pendant des années.

Parlez-nous de votre projet
En pratique

Ce que cette façon de faire change

Les rédacteurs cessent de demander des développeurs

Nouvelles pages, nouvelles sections et nouvelles campagnes sont bâties par l’équipe des communications, et c’est là que se cache habituellement le coût courant d’un site.

Le système de design survit

Deux ans et quatre cents pages plus tard, le site ressemble encore à un seul site, parce que les composants ne permettaient pas autre chose.

L'accessibilité est structurelle

Ordre des titres, points de repère, comportement au clavier et gestion du focus vivent dans le composant. Les rédacteurs ne peuvent pas produire accidentellement une version inaccessible d’un motif existant.

Un changement global est un seul changement

Parce que le balisage est rendu à l’affichage, une correction s’applique à toutes les pages qui utilisent le bloc, y compris celles publiées il y a trois ans.

La migration reste possible

Des attributs structurés plutôt que du HTML enregistré signifient que le contenu peut être réaffiché, réhabillé ou déplacé sans extraire du balisage de la base de données.

Moins d'extensions

Une bibliothèque de blocs couvre ce qu’une pile d’extensions de mise en page, de carrousel, d’accordéon et d’appel à l’action ferait autrement, avec un seul code à maintenir au lieu de huit.

FAQ

Questions fréquentes

  • Est-ce la même chose qu'Elementor ou Divi?

    Non, et la différence est l’endroit où vit le balisage. Un constructeur de pages enregistre la mise en page et le balisage dans la base de données, donc changer un composant plus tard exige de toucher chaque page qui l’utilisait, ou un script de migration qui réécrit le contenu enregistré. Les blocs rendus côté serveur enregistrent des attributs et produisent le balisage depuis le code à l’affichage, donc une correction s’applique partout, y compris aux pages publiées il y a trois ans. Les constructeurs de pages livrent aussi un gros bagage de code à chaque visiteur ; une bibliothèque de blocs ne livre que le balisage dont la page a besoin.

  • Que se passe-t-il si nous changeons de thème plus tard?

    Avec des blocs rendus côté serveur, le contenu survit au changement parce qu’il n’a jamais été du HTML. Les attributs sont des données structurées, donc le même contenu peut être réaffiché avec de nouveaux gabarits ou un nouveau système de design. C’est aussi cette propriété qui rend une future migration possible plutôt qu’un exercice d’archéologie.

  • Les rédacteurs peuvent-ils encore casser le design?

    Beaucoup moins, et c’est délibéré. Les options sont limitées aux choix approuvés par un designer, l’espacement et les conteneurs vivent dans des primitives de mise en page plutôt que dans des réglages par page, et là où la forme de la page compte nous verrouillons les gabarits et restreignons les blocs autorisés. Les rédacteurs obtiennent une vraie liberté sur la disposition des composants et très peu sur leur apparence, ce qui est le partage qui garde cohérent un site de quatre cents pages.

  • De combien de blocs sur mesure un site a-t-il réellement besoin?

    Moins qu’on ne le pense, et le nombre est une décision de conception plutôt qu’un décompte. Ce site en utilise dix-neuf, ce qui couvre toutes ses pages. Les plateformes hypothécaires en ont demandé davantage parce qu’elles portent des répertoires de courtiers, des tableaux de taux et des calculateurs. Une bibliothèque qui n’arrête pas de grossir est généralement le signe que les primitives de mise en page n’étaient pas assez composables.

  • Utilisez-vous l'édition complète du site et les thèmes de blocs?

    De façon sélective. Les thèmes de blocs et theme.json sont une vraie amélioration pour les sites dont les gabarits devraient être modifiables, et nous les utilisons quand c’est le cas. Pour des plateformes au système de design strict, à la gouvernance éditoriale exigeante et aux obligations d’accessibilité, un thème classique avec une bibliothèque de blocs sur mesure donne un contrôle plus serré sur le balisage et sur ce que les rédacteurs peuvent changer. Nous tranchons projet par projet plutôt que par mode.

  • Les blocs sur mesure ralentissent-ils le site?

    Non, et généralement l’inverse. Un constructeur de pages livre à chaque visiteur un gros bagage de JavaScript et de CSS, que la page s’en serve ou non. Un bloc rendu côté serveur produit du balisage simple en PHP, donc une page ne transporte que ce dont elle a réellement besoin et rien n’est assemblé dans le navigateur. Quand un bloc interroge du contenu ou appelle un service externe, la stratégie de cache est décidée pour ce bloc plutôt qu’ajoutée à la fin.

  • Pouvez-vous construire des blocs sur mesure pour le thème que nous avons déjà?

    Habituellement oui, et c’est une bonne façon de commencer. Une bibliothèque de blocs s’enregistre indépendamment du thème, donc les blocs peuvent être ajoutés à une construction existante et adoptés page par page sans refonte. La limite, c’est le thème lui-même : si ses gabarits et sa feuille de style se battent contre le balisage que produisent les blocs, vous finissez par contourner, et à ce moment-là reconstruire le thème coûte moins cher que continuer à rapiécer. Nous vous dirons dans quel cas vous êtes après avoir regardé le code.

  • Nous avons des années de contenu dans l'éditeur classique. Qu'en advient-il?

    Il continue de fonctionner, et il peut être converti. Le contenu classique s’affiche tel quel, donc rien ne casse le jour où la nouvelle bibliothèque arrive. Le convertir en blocs est un travail scripté, exactement le genre de travail que couvre la page migration, et il se fait normalement pour les gabarits et les types de pages qui comptent plutôt que pour toute l’archive.