Intégrer les ressources du thème

[nlambert]

Salut tout le monde,

J’ai parcouru plusieurs fils de discussion à la recherche de réponses — et j’en ai trouvé beaucoup (liens ci-dessous — merci !). Grâce à eux, j’arrive à obtenir la plupart des choses comme je le souhaite. Mais il reste une question à laquelle je n’ai pas pu trouver de réponse.

Elle concerne les fichiers d’assets intégrés, plus précisément le fichier embed_HASH.css.

Il semble que lorsque ces assets sont construits, ils ne sont pas compilés en utilisant la palette de couleurs du thème actif. C’est peut-être intentionnel, ou peut-être quelque chose que j’ai manqué.

Voici ce sur quoi j’aimerais avoir des éclaircissements :

1. Est-ce que embed_[digest].css est toujours construit en utilisant la palette par défaut ?
   Si oui, je peux vivre avec — je sais qu’il y a beaucoup de travail en cours pour améliorer la gestion des thèmes et des palettes de couleurs dans Discourse.
2. S’il peut être construit avec une palette personnalisée, comment puis-je déclencher ce comportement ?
3. J’ai remarqué qu’il peut être construit en utilisant les palettes claire ou sombre du système, il semble donc plausible qu’une palette personnalisée puisse être utilisée — mais je n’ai pas réussi à générer de manière prévisible un fichier d’intégration clair ou sombre.

Pour tester cela, j’ai supprimé tous les thèmes et palettes, tout remis au thème clair par défaut, puis j’ai exécuté :

rake assets:precompile
rake assets:precompile:build

… m’attendant à obtenir un embed_HASH.css à thème clair. Mais le résultat semblait toujours utiliser des styles sombres.

Je ne suis pas très familier avec les rouages internes, donc je pourrais manquer quelque chose d’évident. Si quelqu’un pouvait m’expliquer ce qui est nécessaire pour que le embed_HASH.css soit construit avec une palette prévisible, cela m’aiderait beaucoup.

Merci d’avance !

Pour information, mon instance Discourse fonctionne dans Docker et est à jour. J’ai utilisé le script launcher et le modèle autonome.

Lecture connexe (seulement 2 liens autorisés pour les nouveaux comptes, le 3ème est un titre consultable) :

• How to customize appearance of discourse embeds?
• Styling of Embedded Discourse
• Mode sombre automatique pour les commentaires intégrés également ?

[nlambert]

J’ai trouvé une réponse partielle à ma propre question et je voulais partager cet aperçu :

Le fichier embed_[digest].css est généré à l’aide de la palette de couleurs sélectionnée du thème actif.

Le problème, comme je l’ai réalisé, est dû à une mise en cache très agressive des réponses HTTP.

Ce que j’espère toujours que quelqu’un pourra répondre, c’est :
Où les réponses HTTP pour les fichiers d’assets sont-elles mises en cache dans Discourse ?

Il ne s’agit pas seulement de la mise en cache côté navigateur, mais aussi côté serveur.

---

Lorsque je surveille le journal de production Rails, j’observe que seules les requêtes avec un ensemble de paramètres de requête nouveaux et inédits déclenchent un nouveau rendu d’asset :

$ tail -n 50 shared/standalone/log/rails/production.log -f
Started GET "/stylesheets/embed_afe162195ad0a7185309a19d8c36036d2e53708c.css?__ws=domain.tld&foo=bif" for fd00:aaaa::f1a at 2025-06-27 01:14:38 +0000
Processing by StylesheetsController#show as CSS
  Parameters: {"__ws"=>"domain.tld", "foo"=>"bif", "name"=>"embed_afe162195ad0a7185309a19d8c36036d2e53708c"}
Sent file /var/www/discourse/tmp/stylesheet-cache/embed_afe162195ad0a7185309a19d8c36036d2e53708c.css (0.2ms)
Completed 200 OK in 22ms

Après cela, toute requête ultérieure pour la même URL (même avec des chaînes de requête différentes) renvoie la même réponse, même si le thème sous-jacent a changé.

Par exemple :

1. https://domain.tld/stylesheets/embed_[digest].css?__ws=domain.tld
2. https://domain.tld/stylesheets/embed_[digest].css?__ws=domain.tld&foo=bar

Je ne vois les styles de thème mis à jour que la première fois qu’une requête unique est utilisée. Toutes les requêtes futures avec les mêmes paramètres servent la version précédente, même après recompilation.

Le script launcher utilise par défaut RAILS_ENV=production, et je l’ai laissé tel quel. Je pourrais essayer de passer à RAILS_ENV=development pour désactiver complètement la mise en cache pendant le développement, mais idéalement, j’aimerais savoir :

Comment pouvons-nous vider ou désactiver la mise en cache au niveau HTTP des réponses d’assets en production ?

Si quelqu’un a des informations sur la façon dont Discourse met en cache ces réponses d’assets, ou sur la façon de les invalider correctement, ce serait très utile.

[nlambert]

Oh, man C’était Nginx !

TL;DR :

rm -rf /var/nginx/cache/*`

Correction instantanée !

---

Facultatif : Désactiver la mise en cache des ressources Nginx

Modifiez ce fichier :

/etc/nginx/conf.d/discourse.conf

Autour des lignes 243-246, commentez les directives de mise en cache :

      # proxy_cache one;
      # proxy_cache_key "$scheme,$host,$request_uri";
      # proxy_cache_valid 200 301 302 7d;
      # proxy_cache_bypass $bypass_cache;

Puis redémarrez Nginx :

sv restart nginx

Si vous modifiez les palettes de couleurs…

Modifier simplement les paramètres de couleur dans le thème ne régénérera pas embed_[digest].css. Pour forcer Discourse à générer de nouveaux fichiers de ressources, faites ceci :

rm tmp/stylesheet-cache/* # ou, pour embed uniquement, `rm tmp/stylesheet-cache/embed*`

Qu’en est-il de RAILS_ENV=development ?

Vous pourriez penser que définir RAILS_ENV: development désactiverait la mise en cache, mais :

• Le fichier nginx.sample.conf utilisé par Discourse a la mise en cache activée par défaut, quel que soit l’environnement.
• Cette mise en cache n’est pas liée à RAILS_ENV, elle n’aidera donc pas à la mise en cache des ressources intégrées.

Donc, à moins que vous n’ayez l’intention de reconfigurer entièrement la couche Nginx, il suffit de vider le cache manuellement ou de désactiver ces lignes, et le tour est joué. Une fois que vous êtes prêt pour la production, vous pouvez revenir en arrière.

Qu’en est-il de ./launcher rebuild standalone ?

Bien sûr, cela fonctionne. Mais si vous modifiez activement des thèmes, testez des intégrations et ajustez des couleurs… vous voudrez quelque chose de plus rapide que d’attendre quelques minutes à chaque fois.

Vous avez une meilleure configuration de développement ou des corrections rapides ? Participez !

[system (system) A fermé ce sujet ()]

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.