Assets de theming & SRI
« Assets » signifie tout ce qui n'est pas du contenu écrit : les feuilles de style, les scripts, les fonts, les icônes, et les images qui font que le site et l'interface admin ont l'air corrects. Chinaski les répartit en deux voies avec des règles différentes : une voie site public (traitée par le builder) et une voie app admin (protégée par des hachés d'intégrité). Cette page explique les deux, plus la seule règle qui vaille la peine d'être mémorisée : la règle de rechargement.
La règle de rechargement (mémorisez celle-ci)
Après avoir modifié l'un des cinq fichiers d'assets auto-hébergés de l'app admin sur le disque, redémarrez l'application.
L'interface admin fournit sa propre feuille de style, ses fonts, les fichiers de l'éditeur, et son script de réglages, cinq fichiers, tous checksumés (SRI) au démarrage du processus. Le haché dans chaque page est calculé quand l'application démarre ; si vous remplacez l'un de ces fichiers pendant qu'elle tourne, le navigateur reçoit un fichier qui ne correspond plus au checksum que la page a promis, et il refuse de le charger. Résultat : un admin sans style ou un éditeur cassé.
- Sous systemd :
systemctl restart chinaski@<instance> - Le log de démarrage confirme quand les hachés sont frais : "SRI hashes computed for 5 admin assets."
- Si au contraire un fichier est manquant au démarrage, cet asset se charge sans vérification et le log le dit, restaurez le fichier et redémarrez.
Les pages publiques du site n'ont pas ce cycle de vie ; la règle de rechargement s'applique aux cinq fichiers du bundle admin seulement.
Les assets de thème et comment ils atteignent le site
Les thèmes personnalisés sont des templates plus des références, pas des bundles d'assets :
- Votre CSS/JS est écrit dans le partial
_head.ttdu thème, et ses classes doivent styler les ensembles de classes partagés utilisés par les blocs (voir la Référence des templates). - Les fonts sont auto-hébergées, jamais depuis un CDN. Le jeu de fonts fourni (TTF/WOFF2, avec sous-ensembles par langue) est copié dans la sortie de chaque langue à chaque build ; les thèmes les référencent via la feuille de style fournie.
- Les images : rien n'est bundle ici. Les pages utilisent les images de la médiathèque (qui génère les tailles responsive), le logo du site, et le jeu de favicons.
- Le logo du site : définissez un fichier de logo dans les réglages ; le fichier doit exister dans le répertoire
assets/de l'application, et le builder le copie à la racine du site à chaque build (un logo manquent avertit dans le log de build). - Changements de couleur et de typo sans toucher aux templates : les Design Tokens (Settings) sont la manière supportée de recolorer un thème ; ils deviennent des propriétés personnalisées CSS dans la sortie générée au moment du build.
- Pas de minifier ni de bundler : les fichiers sont fournis tels qu'écrits. Si vous minifiez, vous minifiez à la main ou fournissez des fichiers pré-minifiés ; le builder copie et référence simplement.
Le comportement de cache (à la couche proxy) est par défaut : pages 5 minutes, autres assets 1 jour, fonts un an (elles sont hachées par contenu, donc les mettre en cache pour toujours est sûr). L'application elle-même émet aussi les bons en-têtes, donc la mise en cache se comporte correctement même si vous réécrivez une configuration de proxy.
Favicons et icônes d'application
Vous n'éditez pas à la main les fichiers d'icônes ; vous téléversez une image source dans les réglages, et le système génère tout le jeu :
- Téléversez une image à peu près carrée (PNG/JPEG/SVG/ICO, jusqu'à 5 Mo ; un ratio d'aspect au-delà de 1,25 est rejeté puisque recadrer une bannière large donne une icône inutilisable).
- Le jeu de sortie fixe est généré côté serveur : le favicon du navigateur, l'icône apple-touch, et les deux tailles de manifest d'application (192/512 px), plus favicon.ico.
- Quand activé, chaque build copie ce jeu à la racine du site. Les noms générés sont des constantes partagées entre les réglages et le builder, donc ils ne peuvent pas se désynchroniser.
- Idem pour le logo du site : choisissez son fichier dans les réglages et chaque build le place à la racine du site pour que l'en-tête de votre thème le référence.
Les fonts
Les fonts ne viennent jamais d'un CDN : les polices fournies (y compris les sous-ensembles par écriture) sont des fichiers locaux copiés dans la sortie de chaque langue sous fonts/. Le _head.tt de votre thème les récupère là. Si vous avez besoin d'une police différente, ajoutez des fichiers au répertoire des fonts ; ils sont synchronisés vers chaque langue au prochain build.
Référence rapide : ce qui est traité, et comment
| Type d'asset | Ce qui se passe au build/upload |
|---|---|
| CSS/JS de thème | Écrits dans les templates ; fournis inchangés (pas de minification) |
| CSS/JS admin | Hachés SRI au démarrage ; la règle de rechargement s'applique |
| Fonts | Synchronisés verbatim dans la sortie de chaque langue ; ceux de l'admin enveloppés dans fonts.css |
| Images médias | Tailles dérivées + WebP générés à l'upload (voir Médiathèque) |
| Favicons/icônes | Générés depuis une image source via les réglages |
| Design tokens | Convertis en propriétés personnalisées CSS au moment du build |
La version courte
Les assets du site public sont des copies sans surprise : fichiers entrants, fichiers sortants, règles de cache au proxy. La seule pièce mobile est les hachés SRI du bundle admin : changez l'un de ses cinq fichiers, redémarrez l'application, et si vous voyez un échec d'intégrité dans la console du navigateur sur une page admin, c'est exactement ce qui s'est passé, la boucle de haché périmé (voir la page CSS Blocked (SRI) pour la correction en une étape).