#Assets

Le dossier assets/ contient les fichiers statiques d’un thème : sa feuille de style, ses éventuelles icônes vectorielles. Deux extensions sont admises, .css et .svg, et la liste est fermée.

Cette page explique comment un asset reçoit son adresse, comment il est réellement servi — par une route, et non depuis un disque — et pourquoi il n’y a pas de JavaScript.

#Obtenir l’adresse d’un fichier

Un seul chemin : le filtre asset_url, qui prend le nom du fichier.

{{ 'theme.css' | asset_url | stylesheet_tag }}

<style data-feuille="theme.css">/* le contenu de assets/theme.css */</style>

asset_url colle le nom derrière theme_base, qui vaut /theme-assets/<id-du-thème>. stylesheet_tag pose la feuille dans la page quand elle est un fichier de ton thème de moins de 120 000 caractères ; sinon — feuille plus lourde, ou adresse qui n’est pas un fichier du thème — il rend une balise link vers l’adresse, échappée.

Pourquoi dans la page : la feuille est sur le chemin critique — rien ne s’affiche avant elle — et la route qui la sert lit la base à chaque visite (voir « Le cache » plus bas). Écrite dans le HTML, elle arrive avec lui, il est mis en cache au bord du réseau, et elle se rafraîchit avec lui quand tu enregistres un fichier du thème publié. Ses url() relatives sont ancrées sur theme_base au passage, et un </style> écrit dans un commentaire ne peut pas fermer la balise.

Pour une image :

<img src="{{ 'motif.svg' | asset_url }}" alt="">

#Comment un asset est servi

Pas depuis le disque. La route /theme-assets/<theme>/<fichier> lit le contenu en base, dans la table des fichiers du thème.

Content-Type: text/css; charset=utf-8
Cache-Control: private, max-age=60
Vary: Cookie, Host
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'; style-src 'unsafe-inline'; img-src data:; sandbox
Content-Disposition: inline

Not found

#Pourquoi une route, et pas un fichier statique

Parce que les assets sont modifiables. L’éditeur de code du CMS et le CLI les réécrivent ; un fichier posé sur le disque au moment de l’installation ne suivrait pas. Un thème vit en base une fois installé — voir Anatomie.

#Les quatre gardes de la route

1. L’extension décide du type servi

   .css devient text/css, .svg devient image/svg+xml. Toute autre extension répond 404 avant la moindre requête en base. Renvoyer le type déclaré par le fichier lui-même permettrait de servir du HTML sous le domaine d’un client — donc du script, avec ses cookies.

2. Le nom est revalidé

   Même expression régulière qu’à l’écriture. Le nom est recomposé, jamais concaténé depuis l’URL : ..%2F et autres échappements ne peuvent pas sortir du dossier assets.

3. Le thème doit être publié

   Un brouillon en cours de refonte reste invisible même si l’on devine son identifiant. La lecture publique est ouverte — les visiteurs d’un site n’ont évidemment aucun compte — mais uniquement pour ce qui est en ligne.

4. Le thème doit appartenir au site de l’hôte

   Sans ce test, l’identifiant d’un thème publié suffisait à le faire servir sous le domaine de n’importe quel autre client. C’est l’un des trois défauts qui, composés, ouvraient une exécution de script sous l’origine de n’importe quel site.

#Le cache

Cache-Control: private, max-age=60, avec Vary: Cookie, Host.

private et non public, parce que la réponse dépend de deux choses invisibles dans l’URL : l’hôte appelant, et la session — le propriétaire d’un site en brouillon voit ce qu’un anonyme ne voit pas, et c’est ce qui fait marcher l’aperçu. Un cache partagé pouvait mémoriser la réponse servie au propriétaire et la redistribuer.

La feuille principale n’emprunte plus cette route sur les pages du site : elle est posée dans la page (voir plus haut). La route sert encore les SVG, les feuilles appelées par link, et l’éditeur de code.

Soixante secondes, et c’est court exprès : qui retouche son CSS dans l’éditeur doit voir l’effet en rechargeant, pas dans une heure. Le cache du navigateur reste en place, et c’est lui qui portait l’essentiel du gain — une page vitrine recharge la même feuille de style à chaque écran.

#Ce que la plateforme fait de ta page, après ton thème

Le HTML que ton thème produit passe par quatre corrections avant de partir. Tu n’as rien à écrire pour en profiter ; il faut seulement ne pas les contrarier.

Et sur les pages publiques du site, ton <title>, ta meta charset et ta viewport sont retirées : la page qui accueille ton thème les pose déjà, avec le titre et la description que le client a écrits pour Google. Le titre de ton layout/theme.liquid ne sert donc plus qu’à l’aperçu du Store.

#La feuille de style n’est pas un template

C’est pour cela que les huit thèmes posent leurs réglages en variables CSS dans la coquille, et nulle part ailleurs :

<style>
  :root {
    --accent: {{ settings.accent }};
    --accent-sombre: {{ settings.accent | teinte: -18 }};
    --largeur: {{ settings.largeur }}px;
  }
</style>

.bouton {
  background: var(--accent);
  border-radius: var(--bouton-rayon);
}

.enveloppe {
  max-width: var(--largeur);
  margin-inline: auto;
}

L’avantage n’est pas seulement de faire marcher les réglages : la feuille de style reste un fichier CSS ordinaire, que l’éditeur colore, que le navigateur met en cache, et qu’on peut relire sans démêler du Liquid.

Les huit thèmes n’ont chacun qu’un seul asset — theme.css, de 21 à 79 Ko. Rien n’interdit d’en découper plusieurs : une @import relative depuis theme.css résout bien vers le même dossier servi.

#Ce que la page peut charger d’ailleurs

Un site public est servi avec une politique de sécurité de contenu, et elle borne ce qu’une feuille de style peut aller chercher :

#Les SVG

Admis, et servis avec trois protections qui vont ensemble.

Un SVG est un document scriptable : ouvert dans un onglet, image/svg+xml exécute ses balises script, et nosniff n’y change rien. D’où :

• une CSP sandbox posée par la route elle-même, et non par le proxy — le proxy exclut les chemins finissant par une extension d’image, il ne passe donc jamais sur cette réponse ;
• un Content-Disposition: inline; filename="…", qui laisse le fichier se rendre comme une image dans un img ou en CSS — le seul usage prévu — mais empêche son ouverture directe d’être interprétée comme une page ;
• le nosniff, qui interdit au navigateur de deviner un autre type.

#Pourquoi il n’y a pas de JavaScript

Le blocage est double, et c’est voulu. La liste d’extensions arrête le fichier à l’écriture ; la CSP du site public arrête le script au navigateur, puisque script-src n’admet que l’origine et un nonce que le thème n’a aucun moyen de connaître.

#Ce qu’on fait à la place

Le CSS moderne couvre l’essentiel de ce pour quoi un thème vitrine ouvrait un fichier JavaScript :

Ce dernier mérite un mot : le formulaire de contact de six des huit thèmes d’origine poste vers /api/contacts, la route redirige, et la page se rend à nouveau avec page.demande valant merci ou erreur. Un message de remerciement sans une ligne de script. Voir Objets.

#Les erreurs fréquentes

#Pages voisines