Aller au contenu

#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.

themes/piazza/config/settings_schema.jsonjson
[
  {
    "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
      }
    ]
  }
]
Attention

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 :

GroupeCe qu’on y met
CouleursEncre, papier, accent, texte sur accent, fonds de bandes
TypographiePolice des titres, échelle, casse des surtitres
Mise en pageLargeur, 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.

themes/origo/config/settings_data.jsonjson
{
  "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 } }
    }
  }
}
currentobjetrequis

Les 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.sectionsobjet

Ré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.

Danger

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.

config/settings_data.jsonjson
"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.

Attention

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.

themes/origo/layout/theme.liquidliquid
<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.

Astuce

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é

Note

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 : les default dé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 default de leur propre {% schema %}, qui est lu séparément.
Danger

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 :

liquid
--accent: {{ settings.accent | default: '#4364df' }};

#Les deux fichiers, côte à côte

settings_schema.jsonsettings_data.json
Racineun tableau de groupesun objet avec current
Rôledéclarer ce qui est réglableporter les valeurs
Requisouinon
Lu au rendunonoui
Effet d’un JSON casséaucun au rendusettings vide
Attention

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.

#Pages voisines