Haven't had a chance to look around yet.

We've been working on Aeldris — an AI platform that lets organizations build custom AI assistants trained on their own internal data (PDFs, docs, chats, links, etc.).

Unlike generic chatbots, it uses semantic search agents to understand user intent, so it can handle things like customer service, HR queries, and compliance — without relying on keyword matching.

Drupal powers the content and data layer underneath. Dropped a short demo video if anyone's curious how it all comes together.

Happy to answer questions about the stack or how we approached it.

Hi everyone,

I’m a Drupal developer with 10+ years of experience, currently available for part-time or contract work.

My recent experience has been focused on maintaining and improving existing Drupal sites, including:

- Drupal 9/10/11 upgrades

- Module updates, patching, and dependency fixes

- Debugging issues in core and contributed modules

- Performance improvements and general site maintenance

- Working with CiviCRM-integrated Drupal sites

- Custom module development and enhancements

- Theme customization and front-end adjustments

I’ve worked extensively on live production sites, helping ensure stability, performance, and smooth upgrades.

If you need help with ongoing support, upgrades, customizations, or fixing issues on an existing site, feel free to message me.

Happy discuss further.

Thanks!

Hello,

with excitement I see several topics around HTMX and it looks real promising!

However, I'm not a developer.
Is it anyhow possible to make use of some small HTMX features with using modules or similar?

Basically, what the title says.
There has been the features module / idea long ago and it worked well to create features via the website directly.

Is something like this for recipes in sight?

Looking for some advice - I'm building a page that is designed to have a couple card groups as a staff directory page. I've built out the staff content type and the view with the pertinent fields and have the page built out using multiple template files and SDCs.

This is my flow and it just seems like I'm editing so many files - am I doing this the hardest way possible?

• Content Type -> Staff with general contact fields and an image field
• GUI View Module -> Builds the rows with pertinent fields from my content type (grouped by employee type taxonomy field)
• views-view--staff--block-1.html.twig [Template File] -> calls the subsequent SDC
• views-view—unformatted—staff-directory.twig [SDC] -> Builds the card group <div>, card containers (I.e. container width, padding, etc.), & calls {{ for row in rows }} ...
• views-view-fields--staff--block-1.html.twig [Template File]-> Includes the Card SDC for each row with { fields of interest from the view }
• Card [SDC]

It all works but seems like a lot of files to manipulate just to build a card group. Any help or suggestions would be appreciated.

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