Incorpora Tema degli Asset

Ciao a tutti,

Ho esaminato alcuni thread alla ricerca di risposte e ne ho trovate molte (collegate di seguito, grazie!). Grazie a queste, riesco a far apparire le cose per lo più come voglio. Ma c’è ancora una domanda a cui non sono riuscito a trovare risposta.

Riguarda i file delle risorse incorporate, in particolare il file embed_HASH.css.

Sembra che quando queste risorse vengono create, non vengano compilate utilizzando la palette di colori del tema attivo. Potrebbe essere intenzionale o potrebbe essere qualcosa che mi è sfuggito.

Ecco cosa vorrei chiarire:

  1. embed_[digest].css viene sempre creato utilizzando la palette predefinita?
    Se sì, posso accettarlo: so che ci sono molti lavori in corso per migliorare la gestione dei temi e delle palette di colori in Discourse.
  2. Se può essere creato con una palette personalizzata, come posso attivare quel comportamento?
  3. Ho notato che può essere creato utilizzando le palette chiara o scura del sistema, quindi sembra plausibile che possa essere utilizzata una palette personalizzata, ma non sono riuscito a generare in modo prevedibile un file incorporato chiaro o scuro.

Per testare questo, ho eliminato tutti i temi e le palette, ho reimpostato tutto sul tema chiaro predefinito e poi ho eseguito:

rake assets:precompile
rake assets:precompile:build

…aspettandomi di ottenere un embed_HASH.css a tema chiaro. Ma il risultato sembrava comunque utilizzare stili scuri.

Non ho molta familiarità con gli interni, quindi potrei perdermi qualcosa di ovvio. Se qualcuno potesse condividere ciò che è necessario affinché embed_HASH.css venga creato con una palette prevedibile, sarebbe di grande aiuto.

Grazie in anticipo!

A titolo informativo, la mia istanza Discourse è in esecuzione in Docker ed è aggiornata. Ho utilizzato lo script launcher e il modello standalone.

Letture correlate (sono consentiti solo 2 link per i nuovi account, il terzo è un titolo ricercabile):

Ho trovato una risposta parziale alla mia domanda e volevo condividere l’intuizione:

Il file embed_[digest].css è costruito utilizzando la palette di colori selezionata del tema attivo.

Il problema, come ho capito, è dovuto a una memorizzazione nella cache delle risposte HTTP molto aggressiva.

Ciò che spero ancora che qualcuno possa rispondere è:
Dove vengono memorizzate nella cache le risposte HTTP per i file di asset in Discourse?

Questa non è solo una cache lato browser, sembra essere anche lato server.


Quando si esegue il tail del log di produzione di Rails, osservo che solo le richieste con un nuovo set di parametri di query non visto attivano un nuovo rendering degli 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

Dopo di che, qualsiasi richiesta successiva per lo stesso URL (anche con stringhe di query diverse) restituisce la stessa risposta, anche se il tema sottostante è cambiato.

Ad esempio:

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

Vedo gli stili del tema aggiornati solo la prima volta che viene utilizzata una query univoca. Tutte le richieste future con gli stessi parametri servono la versione precedente, anche dopo la ricompilazione.

Lo script launcher utilizza per impostazione predefinita RAILS_ENV=production e ho lasciato così com’è. Potrei provare a passare a RAILS_ENV=development per disabilitare completamente la cache durante lo sviluppo, ma idealmente vorrei sapere:

Come possiamo cancellare o disabilitare la memorizzazione nella cache a livello HTTP delle risposte degli asset in produzione?

Se qualcuno ha informazioni su come Discourse memorizza nella cache queste risposte degli asset, o su come invalidarle correttamente, sarebbe molto utile.

1 Mi Piace

Oh, cavolo :flushed_face: Era Nginx!

TL;DR:

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

Soluzione istantanea!


Opzionale: Disabilita la cache degli asset di Nginx

Modifica questo file:

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

Intorno alle righe 243-246, commenta le direttive di caching:

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

Quindi riavvia Nginx:

sv restart nginx

:artist_palette: Se stai modificando le palette di colori…

La semplice modifica delle impostazioni del colore nel tema non rigenererà embed_[digest].css. Per forzare Discourse a generare nuovi file di asset, fai questo:

rm tmp/stylesheet-cache/* # oppure, solo per embed, `rm tmp/stylesheet-cache/embed*`

:thinking: E per quanto riguarda RAILS_ENV=development?

Potresti pensare che impostare RAILS_ENV: development disabiliti la cache, ma:

  • Il file nginx.sample.conf utilizzato da Discourse ha la cache abilitata per impostazione predefinita, indipendentemente dall’ambiente.
  • Tale cache non è legata a RAILS_ENV, quindi non aiuterà con la cache degli asset incorporati.

Quindi, a meno che tu non abbia intenzione di riconfigurare completamente il livello Nginx, svuota semplicemente la cache manualmente o disabilita quelle righe, e sei a posto. Una volta che sei pronto per la produzione, puoi ripristinare le modifiche.

:turtle: E per quanto riguarda ./launcher rebuild standalone?

Certo, funziona. Ma se stai modificando attivamente temi, testando embed e ottimizzando colori… vorrai qualcosa di più veloce che aspettare qualche minuto ogni volta.

:speech_balloon: Hai una configurazione di sviluppo migliore o soluzioni rapide? Partecipa!

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