Embed Assets Theme

Support
1

Hey folks,

I’ve gone through a few threads looking for answers — and I’ve found many (linked below — thank you!). Thanks to those, I can get things mostly looking the way I want. But there’s still one question I haven’t been able to solve.

It concerns the embed asset files, specifically the embed_HASH.css file.

It appears that when these assets are built, they’re not compiled using the active theme’s color palette. That might be by design, or it might be something I’ve missed.

Here’s what I’d love clarity on:

  1. Is embed_[digest].css always built using the default palette?
    If so, I can live with that — I know there’s a lot of ongoing work to improve how themes and color palettes are handled in Discourse.
  2. If it can be built with a custom palette, how can I trigger that behavior?
  3. I’ve noticed it can be built using the system’s light or dark palettes, so it seems plausible that a custom palette could be used — but I haven’t been able to predictably generate a light or dark embed file.

To test this, I deleted all themes and palettes, set everything back to the default Light theme, and then ran:

rake assets:precompile
rake assets:precompile:build

…expecting to get a light-themed embed_HASH.css. But the result still appeared to use dark styles.

I’m not deeply familiar with the internals, so I may be missing something obvious. If anyone could share what is required so that the embed_HASH.css is built with a predictable palette, it would really help.

Thanks in advance!

FYI, my Discourse instance is running in Docker and it’s up to date. I’ve used the launcher script and the standalone template.

Related reading (only 2 links allowed for new accounts, 3rd is a searchable title):

2

I’ve found a partial answer to my own question and wanted to share the insight:

The embed_[digest].css file is built using the active theme’s selected color palette.

The issue, as I’ve come to realize, is due to very aggressive HTTP response caching.

What I’m still hoping someone can answer is:
Where are the HTTP responses for asset files cached in Discourse?

This isn’t just browser-side caching — it appears to be server-side as well.

When tailing the Rails production log, I observe that only requests with a new, unseen set of query parameters trigger a fresh asset render:

$ 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

After that, any subsequent requests for the same URL (even with different query strings) return the same response — even if the underlying theme has changed.

For example:

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

I only see updated theme styles the first time a unique query is used. All future requests with the same parameters serve the previous version, even after recompilation.

The launcher script defaults to RAILS_ENV=production, and I’ve left that as-is. I could try switching to RAILS_ENV=development to disable caching entirely during development, but ideally, I’d like to know:

How can we clear or disable HTTP-level caching of asset responses in production?

If anyone has insight into how Discourse caches these asset responses — or how to properly invalidate them — that would be really helpful.

1 Like
3

Oh, man :flushed_face: It was Nginx!

TL;DR:

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

Instant fix!

Optional: Disable Nginx asset caching

Edit this file:

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

Around lines 243-246, comment out the caching directives:

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

Then restart Nginx:

sv restart nginx

:artist_palette: If you’re changing color palettes…

Just editing the color settings in the theme won’t regenerate embed_[digest].css. To force Discourse to generate new asset files, do this:

rm tmp/stylesheet-cache/* # or, for embed only, `rm tmp/stylesheet-cache/embed*`

:thinking: What about RAILS_ENV=development?

You might think that setting RAILS_ENV: development would disable caching, but:

  • The nginx.sample.conf used by Discourse has caching enabled by default, regardless of environment
  • That caching is not tied to RAILS_ENV, so it won’t help with embedded asset caching

So unless you plan to fully reconfigure the Nginx layer, just clear the cache manually or disable those lines, and you’re good. Once you’re ready for production, you can revert back.

:turtle: What about ./launcher rebuild standalone?

Sure, it works. But if you’re actively tweaking themes, testing embeds, and tuning colors… you’ll want something faster than waiting a few minutes everytime.

:speech_balloon: Got a better dev setup or quick fixes? Chime in!