If a file has a Status of Temporary the file in the filesystem can still be accessed (say, when themake_unused_managed_files_temporary configuration value is set to true (default is 0) in the file.settings.yml config file and a file becomes unused).

Often, if unused managed files become temporary it's because an author has replaced a file used on a media item with a newer version. Often this new version corrects some defect in the original document and it is therefore undesirable to maintain public access to the older file.

If you're having Drupal garbage collect temporary files you may have a few hours in which that old file is publicly available until it is deleted on cron (depending on the value of temporary_maximum_age in file.settings.yml). I'm primarily thinking about hotlinks to the files or the external experiences of having files surfaced via search or AI.

Is there a smart way to ensure these temporary files aren't accessible? Perhaps having them moved to private file storage until they're deleted? Would love some feedback here – there's not a lot of advice available in this area of file/media management and I'm managing a library of 10k+ items.

Two years ago I shared a proof of concept for server-rendering Lit web components in Drupal using a Node.js sidecar container. It worked, but the feedback was fair: nobody wants to run Node.js alongside Drupal, manage inter-container networking, or babysit an extra process in production.

Backlit is the version I actually want to use:

composer require bennypowers/backlit drush en backlit

That's the entire install. Composer downloads the right pre-compiled binary for your OS and architecture. Drush enables the module. Every page response now gets its Lit components server-rendered with Declarative Shadow DOM -- styles and layout on first paint, before JavaScript loads.

How it works: Backlit starts a long-running child process (the binary) inside your PHP-FPM worker. HTML goes in via stdin, rendered HTML comes out via stdout. The binary embeds a WASM module containing @lit-labs/ssr. Cold start is ~350ms once per worker; per-render is ~0.32ms. With Drupal's page cache in front, subsequent requests never touch the binary at all.

A few practical details:

• Drop component JS files in your theme's components/ directory; Backlit auto-discovers them from customElements.define() calls
  
• If the binary fails for any reason, Backlit returns the original HTML unchanged -- SSR failure is invisible to users
  
• Authors get a per-content "Enable SSR" checkbox for pages where it causes issues
  
• composer update bennypowers/backlit handles binary updates

This is a v0 release. Lit only (via @lit-labs/ssr), no streaming, one process per worker. Honest about limitations. I'd love to hear what breaks on real sites.

Post: https://bennypowers.dev/posts/drupal-lit-ssr-wasm/ Module: https://github.com/bennypowers/backlit Demo repo: https://github.com/bennypowers/drupal-lit-ssr-wasm