#Le bloc schema
Le {% schema %} d’une section déclare ce qui, dans cette section, est
modifiable sans toucher au code : son nom, ses réglages, ses blocs. C’est du
JSON pur, posé à la fin du fichier, entre {% schema %} et
{% endschema %}.
Il ne s’exécute pas et ne rend rien. Il est retiré du fichier avant le rendu, puis relu séparément pour en tirer les valeurs par défaut.
#La forme
<section class="temoignages">
<h2>{{ section.settings.titre }}</h2>
{%- for bloc in section.blocks -%}
<blockquote>« {{ bloc.settings.citation }} »</blockquote>
{%- endfor -%}
</section>
{% schema %}
{
"name": "Avis clients",
"settings": [
{ "type": "text", "id": "titre", "label": "Titre", "default": "Ce qu'ils en disent" }
],
"blocks": [
{
"type": "avis",
"name": "Avis",
"settings": [
{ "type": "textarea", "id": "citation", "label": "Citation" },
{ "type": "text", "id": "auteur", "label": "Auteur", "default": "Un client" }
]
}
],
"max_blocks": 6
}
{% endschema %}Du JSON, pas du JavaScript et pas du Liquid. Pas de commentaires, pas de
virgule finale, pas de guillemets simples, aucune expression {{ }} à
l’intérieur. Le bloc est extrait par expression régulière et passé à
JSON.parse tel quel.
#Les clés
namechaînerequisLe nom lisible de la section. C’est lui qui identifie la section pour qui relit le thème ou compose une page.
settingstableauLes réglages de la section, dans l’ordre d’affichage. Chaque entrée porte au
minimum un type ; celles qui portent une valeur ont aussi un id et un
label. Voir Les types de réglage.
blockstableauLes types de bloc que la section accepte. Chaque entrée porte type,
name, et ses propres settings. Voir Les blocs.
max_blocksentierNombre maximal de blocs. origo va de 4 pour le bandeau (hero) et les
tarifs à 30 pour les blocs de texte libre (texte, zone).
groupheader | footer | templateDit que la section est posée par la coquille avec {% section %}, et non par
un template. Purement documentaire aujourd’hui.
presetstableauLes compositions proposées à l’ajout de la section : un name, et des
settings et blocks de départ. Aucun des quatre thèmes d’origine n’en
déclare.
tagchaîneLa balise HTML dans laquelle Shopify enveloppe la section. Sans effet ici : Webcosa n’enveloppe rien, c’est la section qui écrit sa propre balise racine.
classchaîneLes classes de cette enveloppe. Sans effet, pour la même raison.
Ce que le moteur lit réellement, aujourd’hui, c’est settings — et dans
settings, uniquement id et default. Tout le reste (name, label,
info, blocks, max_blocks, group, presets, tag, class) est
déclaratif : le rendu ne s’en sert pas, et rien ne le fait respecter à
l’écriture.
Ce n’est pas une raison pour l’écrire à la légère. Un schéma est le contrat de
la section, il est relu par des humains, et il sera lu par le panneau de
réglages le jour où il existera. Un max_blocks juste vaut mieux qu’un
max_blocks décoratif.
#Ce que le schéma fait vraiment au rendu
Une seule chose, et elle est importante : fournir les valeurs par défaut.
Le schéma est extrait
Une expression régulière cherche
{% schema %}…{% endschema %}, tolérant les formes à tirets ({%- schema -%}). Le contenu est passé àJSON.parse.Les défauts sont collectés
Pour chaque entrée de
settingsqui a unidet undefault, la valeur par défaut est retenue. Une entrée sansid— unheader, unparagraph— n’apporte rien ; une entrée sansdefaultnon plus.Les valeurs enregistrées recouvrent les défauts
section.settingsest le résultat de la fusion : les défauts d’abord, les valeurs du template ou desettings_data.jsonpar-dessus.Le bloc schema est retiré du fichier
La même expression régulière le supprime avant que le balisage ne soit rendu. C’est pour ça qu’un
{% schema %}ne produit jamais de sortie.
Cette fusion est ce qui permet d'ajouter un réglage à un thème déjà
installé : les instances existantes ne connaissent pas le nouvel id, elles
prennent donc le default. Sans elle, l’auteur du thème croirait son défaut
ignoré et irait rouvrir toutes les pages.
Les défauts ne sont fusionnés que pour les réglages de section. Les
réglages de bloc ne reçoivent jamais leur default : un bloc dont le
template ne renseigne pas un champ rend du vide, même si le schéma déclare une
valeur par défaut. Voir Les blocs.
#Ce qui se passe si le JSON est invalide
lireSchema rend null, et le rendu continue. Concrètement :
- la section reste rendable — son balisage s’affiche ;
- elle perd toutes ses valeurs par défaut :
section.settingsne contient plus que ce que le template a explicitement enregistré ; - sur une section fraîchement posée, dont le template n’a rien enregistré, cela veut dire une section vide.
C’est délibéré. Une virgule en trop dans un schéma ne doit pas éteindre une page en ligne — mais le résultat est assez visible pour qu’on aille corriger tout de suite.
Le JSON du schéma n’est pas vérifié à l’enregistrement. L’API contrôle la
syntaxe Liquid des .liquid après avoir retiré le bloc schema, et le JSON
des .json — un schéma cassé passe donc entre les deux. Il ne se découvre
qu’au rendu, sous la forme d’une section sans réglages.
#La reconnaître
{
"name": "Prestations",
"settings": [
{ "type": "text", "id": "titre", "label": "Titre", "default": "Nos services" },
]
}La virgule après la dernière entrée. JSON.parse refuse, lireSchema rend
null, et la section perd ses défauts. Un formateur JSON dans l’éditeur
l’attrape en une seconde ; à l’œil nu, on peut y passer un quart d’heure.
#Deux règles de forme
Un seul bloc schema par fichier. L’expression régulière n’en trouve
qu’un et n’en retire qu’un : le second serait rendu tel quel et ferait échouer
la section avec tag "schema" not found, puisque schema n’est pas un tag
exécutable.
Jamais dans un layout ni dans un snippet. Ces fichiers sont rendus sans
retrait préalable du bloc. Un {% schema %} dans layout/theme.liquid casse
toutes les pages du site d’un coup.
#Un schéma bien écrit
info est le champ le plus sous-utilisé du format, et c’est dommage : c’est
la seule occasion d’expliquer à quoi sert un réglage à l’endroit où on le
remplit.
{
"type": "range",
"id": "densite",
"label": "Espace entre les sections",
"info": "Plus haut, le site respire ; plus bas, il tient sur moins d'écrans.",
"min": 60,
"max": 160,
"step": 10,
"unit": "%",
"default": 100
}Trois habitudes qui se retrouvent dans les quatre thèmes :
- un
defaultsur tout ce qui est visible. Un thème installé doit ressembler à quelque chose avant qu’on l’ouvre ; - pas de
defaultsur ce qui est facultatif. Une adresse, un téléphone : vide, la section masque proprement l’élément ; infopour dire l’effet, pas le champ. « Laisse vide pour masquer la barre » vaut mieux que « Le texte de l’annonce ».

