#Réglages globaux
Les réglages globaux valent pour le thème entier : les couleurs, la largeur du
contenu, la typographie, l’arrondi des angles. Ils se lisent partout avec
settings.<id> — dans la coquille, dans une section, dans une section de
pied de page.
Deux fichiers, et la distinction entre les deux est toute la page :
config/settings_schema.json déclare ce qui est réglable,
config/settings_data.json valorise ces réglages pour ce site.
#settings_schema.json — déclarer
Un tableau de groupes. Chaque groupe porte un name — l’intertitre du
panneau — et un tableau settings aux mêmes treize types que les schémas de
section.
[
{
"name": "Couleurs",
"settings": [
{ "type": "color", "id": "encre", "label": "Fond sombre et texte", "default": "#2b1b12" },
{ "type": "color", "id": "papier", "label": "Fond de page", "default": "#ffffff" },
{ "type": "color", "id": "accent", "label": "Accent", "default": "#b45309" },
{ "type": "color", "id": "creme", "label": "Crème", "info": "Le fond des bandes claires.", "default": "#fdf4e6" }
]
},
{
"name": "Mise en page",
"settings": [
{
"type": "range",
"id": "largeur",
"label": "Largeur du contenu",
"min": 960,
"max": 1440,
"step": 40,
"unit": "px",
"default": 1160
}
]
}
]Un tableau à la racine, pas un objet. C’est la seule différence de forme
avec un {% schema %} de section, et c’est la faute qu’on fait une fois.
Le fichier est requis dans tout thème : [] est un contenu valable, un objet
{} ne l’est pas plus qu’autre chose mais ne servira à rien.
Les quatre thèmes s’organisent tous de la même façon, et ça vaut la peine de copier le découpage :
| Groupe | Ce qu’on y met |
|---|---|
| Couleurs | Encre, papier, accent, texte sur accent, fonds de bandes |
| Typographie | Police des titres, échelle, casse des surtitres |
| Mise en page | Largeur, arrondi, densité, forme des boutons |
#settings_data.json — valoriser
Un objet, avec une clé current. Tout ce qui est sous current devient
un réglage global — sauf une clé réservée, sections.
{
"current": {
"encre": "#15171c",
"papier": "#ffffff",
"voile": "#f5f5f7",
"accent": "#4364df",
"accent_texte": "#ffffff",
"police_titres": "systeme",
"echelle": 100,
"largeur": 1160,
"arrondi": 12,
"densite": 100,
"boutons": "pilule",
"sections": {
"annonce": { "settings": { "texte": "Devis gratuit sous 48 h" } },
"entete": { "settings": { "cta_label": "Nous contacter", "cta_href": "/contact" } },
"pied": { "settings": { "mentions": true } }
}
}
}currentobjetrequisLes valeurs actives. Le nom vient de Shopify, où settings_data.json peut
aussi porter des préréglages nommés à côté de current ; Webcosa ne lit
que current, le reste est stocké et ignoré.
current.sectionsobjetRéservée. Elle porte les valeurs des sections que la coquille pose avec
{% section %} — en-tête, pied, barre d’annonce — et n’apparaît jamais
dans settings.
Un réglage global qui s’appellerait sections serait avalé par cette clé
réservée : settings.sections n’existe pas, et les valeurs seraient
interprétées comme des sections de coquille. C’est le seul nom d’id à
éviter absolument.
#La clé sections — les sections de la coquille
L’en-tête et le pied ne sont dans aucun template : ils apparaissent sur toutes les pages. Leurs réglages n’ont donc nulle part où aller, sinon ici.
"sections": {
"entete": {
"settings": { "cta_label": "Nous contacter", "cta_href": "/contact" }
},
"pied": {
"settings": { "mentions": true },
"blocks": [
{ "type": "reseau", "settings": { "reseau": "Instagram", "href": "https://instagram.com/atelier" } }
]
}
}La clé est le nom de la section, celui du {% section 'entete' %} de la
coquille — donc le nom du fichier. Chaque entrée accepte settings et
blocks.
Ici, blocks est un tableau, pas l’objet indexé par identifiant des
templates : il est passé au rendu tel quel. Voir Les blocs.
Les default du schéma de la section sont bien appliqués sous ces valeurs :
une section de coquille qu’on ne renseigne pas du tout rend avec ses défauts.
#Lire un réglage global
Partout, avec settings.<id>. La forme canonique est de les convertir en
variables CSS dans la coquille, et nulle part ailleurs.
<style>
:root {
--encre: {{ settings.encre }};
--papier: {{ settings.papier }};
--accent: {{ settings.accent }};
--accent-sombre: {{ settings.accent | teinte: -18 }};
--accent-clair: {{ settings.accent | teinte: 88 }};
--largeur: {{ settings.largeur }}px;
--arrondi: {{ settings.arrondi }}px;
--bouton-rayon: {% if settings.boutons == 'droit' %}4px{% else %}999px{% endif %};
}
</style>Aucune section n’a alors besoin de connaître une couleur : elles héritent
toutes de :root, et assets/theme.css reste un fichier CSS ordinaire, sans
une ligne de Liquid.
Un réglage global lu directement dans une section — {{ settings.accent }}
dans un attribut style — fonctionne, mais il disperse la logique de style et
casse la mise en cache du CSS. Réserve-le aux cas qu’une variable CSS ne sait
pas exprimer.
#Ce qui se passe quand le JSON est cassé
settings_data.json illisible : le thème rend avec les valeurs par défaut
de ses schémas. Laid, mais lisible — et l’erreur saute aux yeux dans
l’éditeur de code.
Concrètement, un JSON invalide donne settings vide et sections vide.
Deux conséquences distinctes :
- les réglages globaux retombent sur… rien. Il n’y a pas de fusion avec
settings_schema.json: lesdefaultdéclarés là ne sont jamais appliqués.{{ settings.accent }}rend une chaîne vide, et la variable CSS--accent:devient invalide — donc les couleurs du navigateur ; - les sections de coquille, elles, retombent bien sur les
defaultde leur propre{% schema %}, qui est lu séparément.
C’est une asymétrie à connaître : le default d’un réglage global n’est
qu’une documentation. Ce qui alimente settings est uniquement
settings_data.json. Un thème dont on livre le settings_schema.json sans
settings_data.json rend sans aucune couleur.
Corollaire : ajouter un réglage global à un thème déjà installé demande
deux modifications — la déclaration dans settings_schema.json, et la
valeur dans settings_data.json. Oublier la seconde donne une page qui ne
change pas, sans un mot d’erreur.
Une parade utile dans la coquille, tant que l’oubli reste possible :
--accent: {{ settings.accent | default: '#4364df' }};#Les deux fichiers, côte à côte
settings_schema.json | settings_data.json | |
|---|---|---|
| Racine | un tableau de groupes | un objet avec current |
| Rôle | déclarer ce qui est réglable | porter les valeurs |
| Requis | oui | non |
| Lu au rendu | non | oui |
| Effet d’un JSON cassé | aucun au rendu | settings vide |
settings_schema.json n’est lu par aucun code de rendu aujourd’hui. Il
est requis à l’installation, il est le contrat du thème, il sera lu par le
panneau de réglages — mais rien, au moment de servir une page, ne l’ouvre.
C’est ce qui explique la ligne « Lu au rendu : non ».
#Ce qui vaut la peine d’être un réglage global
Ce qui doit changer partout d’un coup : couleurs, largeur, typographie, arrondi. Le test est simple — si le régler section par section serait une corvée, il est global.
Ce qui n’en est pas un : les titres, les textes, les images. Ils appartiennent à une section, et un réglage global qui ne sert qu’à un endroit est un réglage qu’on cherchera dans le mauvais panneau.
Les quatre thèmes tiennent entre 5 et 12 réglages globaux. Au-delà, un panneau
ne se remplit plus — et c’est précisément à quoi sert le filtre teinte :
dériver les nuances d’une couleur au lieu de les demander une par une.

