Types de blocks

Chaque block dans Chinaski, d’une bande d’appel à l’action à un tableau de prix, appartient à un type, le vocabulaire qui indique au système quels champs il prend et comment il est rendu. Cette page couvre le registre des types lui-même : les types intégrés livrés avec le logiciel, comment enregistrer les vôtres, et les règles qui maintiennent les deux en phase.

Le registre

Les types de blocks vivent dans une table gérée, la source unique de vérité sur les types qui existent. Ce que le registre décide :

Si un block de ce type peut être créé (créer un block exige que son type soit enregistré ; basculer un block existant vers un type non enregistré est refusé).
Ce qui apparaît dans l’éditeur de blocks, les écrans de la Library, et les menus déroulant(s) de type d’auteur ailleurs dans l’admin.
Quels types de blocks un fichier d’import de blocks peut référencer.

Au démarrage, le registre est synchronisé avec le vocabulaire livré avec le logiciel : les types standards sont réinsérés, en reprenant les modifications que vous avez apportées à leurs libellés ou descriptions. L’ensemble livré, listé par ordre alphabétique sur l’écran Block Types, est volontairement large :

accordion, audio, button_group, callout, citations, code_block, columns, cta, divider, embed, faq, feature_grid, form, gallery, grid, heading, hero, image, logo_bar, newsletter, page_list, pricing_table, promo, quote, schedule, spacer, stat, table, team, testimonial, text, timeline, video

Créer un type de block personnalisé (le formulaire)

Sur l’écran Block Types (administrateurs uniquement), le formulaire Register Custom Block Type prend trois champs :

Name : lettres minuscules, chiffres, tirets et underscores uniquement ; il devient l’identifiant du type (ce qui vit dans la colonne type et les formulaires).
Label : le nom lisible utilisé dans les listes (par défaut la forme courte en majuscules ; vous pouvez la remplacer).
Description : texte libre facultatif.

La soumission enregistre le type instantanément ; il n’y a aucun fichier de rendu à ajouter côté serveur. Les messages flash du système font le reste :

“Block type registered” si les deux fichiers requis existent déjà (voir ci-dessous).
Le message flash vous indique précisément les chemins de fichiers manquants. Le type enregistré reste dans le registre ; il ne sera simplement pas rendu et n’affichera pas son formulaire d’admin tant que ces deux fichiers n’existent pas.

Ce dont un type personnalisé a besoin

Deux fichiers, à placer vous-même :

builder/block_templates/<type>.tt, le template du builder : c’est ce qui est rendu dans le site (voir Blocks in Themes pour le contrat de variables).
templates/admin/blocks/types/<type>.html.ep, le formulaire d’admin : quels champs l’éditeur du block expose (ce qui signifie souvent ses champs plats, ou un éditeur de lignes JSON pour des données répétitives de style grid/gallery/columns).
Le registre ne déplace pas les blocks. Le type détermine quels champs apparaissent dans le formulaire d’admin ; le template du builder décide du rendu, et c’est le nom du block, pas son type, que les {{block:name}} référencent.
Les types personnalisés n’ont pas de scaffolding. Le formulaire d’enregistrement vous dit quels deux chemins de fichiers créer, mais ne fabrique jamais les templates pour vous.

Supprimer un type

Deux sortes de types de blocks sont sur l’écran, et les deux catégories se comportent différemment :

Les types intégrés ne peuvent pas être supprimés. Le processus de démarrage re-sème la liste standard à chaque démarrage, et le contenu existant d’un type intégré ne peut pas rester editable-less.
Les types personnalisés peuvent être supprimés, mais seulement vides. Tout block encore dans le type bloque la suppression avec une erreur (“blocks of this type still exist”) ; vous devez mettre à la corbeille ou détruire chaque block de ce type d’abord (ensuite, depuis l’écran Blocks, seuls les types personnalisés enregistrés peuvent être supprimés/retirés du registre).

L’écran du registre reste donc propre : chaque entrée y est soit un type actif que les formulaires d’admin référencent, soit un type personnalisé prêt à supprimer une fois vidé.

Ajouter un type sans coder des blocks de zéro

Créer une variante d’un type existant, partageant les mêmes champs mais avec un autre nom et une autre intention de style, est légitime :

Enregistrez le nouveau nom sur l’écran Block Types.
Copiez le template de block du builder (<name>.tt) et le partial de formulaire d’admin (<type>.html.ep) du type le plus proche de ce dont vous avez besoin ; ces deux fichiers copiés sont le même contrat.
Ajustez les champs du formulaire et le HTML du template selon les besoins.

Le même soin s’applique en venant de l’extérieur de l’ensemble intégré (voir la section de la page Blocks sur quels champs acceptent le HTML vs. l’auto-échappement).

La version courte

Les types intégrés sont le vocabulaire fixe pour lequel les templates de blocks et les formulaires d’admin sont construits ; le registre décide quels types existent ; les admins peuvent enregistrer les leurs (en copiant à la main deux fichiers de template), et un type personnalisé peut être supprimé une fois vidé, tandis que les intégrés restent perpétuels parce que la seed les fait tourner à chaque démarrage.