Développement de blocs Gutenberg

Non. La différence tient à l’endroit où vit le balisage. Un constructeur de pages enregistre la mise en page et le balisage dans la base de données. Changer un composant plus tard oblige alors à retoucher chaque page qui l’utilise, ou à lancer un script qui réécrit le contenu enregistré. Les blocs rendus côté serveur enregistrent des réglages et produisent le balisage à partir du code quand la page est demandée, donc une correction s’applique partout, même aux pages publiées il y a des années. Un constructeur de pages envoie aussi un lourd bagage de code à chaque visiteur, alors qu’une bibliothèque de blocs n’envoie que le balisage utile.

Avec des blocs rendus côté serveur, le contenu survit au changement, parce qu’il n’a jamais été enregistré en HTML. Les réglages des blocs sont des données structurées, et le même contenu peut être affiché avec de nouveaux gabarits ou un nouveau système de design. C’est aussi ce qui fait d’une future migration un travail planifié plutôt qu’une fouille archéologique.

Beaucoup moins, et c’est voulu. Les options se limitent aux choix approuvés par un designer, l’espacement et les conteneurs sont gérés par les blocs de mise en page plutôt que page par page, et là où la forme compte, nous verrouillons les gabarits et limitons les blocs permis. Les rédacteurs gardent une vraie liberté sur l’agencement et très peu sur l’apparence de chaque composant. C’est cet équilibre qui garde un gros site cohérent.

Moins qu’on le pense, et le nombre découle de choix de conception. Une plateforme avec des répertoires, des données tirées d’un autre système et des formulaires de demande en demande plus qu’un site vitrine. Une bibliothèque qui ne cesse de grossir signale souvent des blocs de mise en page pas assez combinables.

Au cas par cas. Les thèmes de blocs et theme.json sont un vrai progrès pour les sites dont les gabarits doivent pouvoir être modifiés, et nous les utilisons dans ces cas-là. Pour une plateforme au système de design strict, avec une gouvernance éditoriale et des 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 décidons projet par projet.

Non, c’est plutôt l’inverse. Un constructeur de pages envoie à chaque visiteur un lourd 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 : la page ne transporte que ce dont elle a besoin, et rien n’est assemblé dans le navigateur. Quand un bloc interroge du contenu ou va chercher des données ailleurs, nous décidons de sa mise en cache en le construisant.

En général, oui, et c’est une bonne façon de commencer. Une bibliothèque de blocs s’enregistre indépendamment du thème. Les blocs peuvent donc s’ajouter à un site existant et être 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 des blocs, on finit par contourner, et refaire le thème coûte alors moins cher que de le rapiécer. Nous vous dirons où vous en êtes après avoir lu le code.

Il continue de fonctionner, et il peut être converti. Le contenu classique s’affiche tel quel, donc rien ne brise le jour où la nouvelle bibliothèque arrive. La conversion en blocs se fait par script, le genre de travail que décrit notre page sur la migration, et elle vise d’habitude les gabarits et les types de pages qui comptent plutôt que toutes les archives.