i was able to update and upgrade my sites with ai, before nobody could help....i spend several days on slack, messaging also dev of specific theme...no answer.....ai knew everything. I havent visited slack now for over a year. For like moderate tasks in drupal ai is winner....it knows aeverything about every little module and you save like 99 % of the time...it is just amazing..... it knows ddev, docker, upgrades....altering theme...you name it....this is a major thing, because people on slack ususally are not the most friendliest

I’m working on a Drupal project that requires building a simple document library page.

The idea is to have a single page that displays a few categories/buildings. When a user clicks a category, the category page opens and displays all PDFs related to it.

On the category page, I also need:

• search by file name only
• pagination, since each category can have a lot of PDFs

I mainly need help with how to start and structure this properly, since I only started working with Drupal last year and haven’t really built anything like this from scratch before.

Would you use content types + file fields, Media, taxonomy, Views, or some mix of these?

​

If everyone's making Drupal headless all these years why haven't they just refactored/updated the UI of Drupal to incorporate a faster UI?

It seems like reinventing the wheel to completely refactor the UI on top of a framework that is designed to work in a more secure manner?

Maybe I'm confused as to why people do this?

Disclaimer: I used AI to polish the phrasing of this post, but the content and concerns are entirely my own. Thanks for reading!

Hi everyone,

I’m a software engineering intern based in Vietnam, currently working at a small boutique agency that specializes in Drupal. Our dev team is tiny: just me, one senior dev, and our boss. Recently, the senior dev resigned, and my boss approached me to ask about my long-term plans. He wants to know if I intend to stay after graduation and commit to Drupal, or if I’m planning to move on.

To be honest, I’m torn. When I first started, I hated Drupal. I couldn’t wrap my head around how it worked—the modules, the hooks, and the way it handled CSS felt so counter-intuitive. I remember writing over 4,000 lines of CSS just for a few pages! However, after some time, I’ve managed to "tame the beast." I can now confidently say I’m proficient in Drupal development (though I’m still a novice when it comes to DevOps or Networking).

But here’s my concern: compared to the hype and job volume of Node.js, Laravel, or Angular, Drupal feels very "restrictive." In Vietnam specifically, the job market for Drupal is incredibly small. This makes me wonder: can I actually build a strong career with Drupal as my primary strength, or should I just treat this as a phase to improve my general programming logic, UI, and UX?

My ultimate goal is to work for large corporations or international companies where the pay is high. I know Drupal is used by big players, but I’m worried that the "entry gate" for those roles might be too narrow. Am I betting on the wrong horse, or should I pivot to a more mainstream stack now before I get too deep?

I can always use AI to help bridge the technical gaps, but I know that choosing a career path is a decision no AI can make for me.

So, to the experienced devs out there: Should I double down on Drupal, master it, and hunt for those high-paying enterprise roles? Or is it wiser to start fresh with a more popular framework?

I would really appreciate any advice or perspectives you can share. Thank you!

Apologies in advance for what might come across as a string of stupid questions.

Our org uses Optasy for web development. We originally picked them because of their experience with Drupal and needed help moving from Drupal 7 to D10/11. To their credit, they did an excellent job on that project.

But our needs have shifted in the year since then. Over the past six months, we've found their communication/responsiveness to be extremely poor, to the point that we're starting to look at other options. I want to think it's because we've asked to scale down to a minimal, security-focused SLA, but others in our org think it's because we declined to sign another contract and have stayed month-to-month.

I understand that our current needs don't make us a huge client, but it's still frustrating to wait months for responses on pretty basic requests, like downgrading our Pantheon plan, etc.

And while I hate putting them on blast like this, I couldn't find much discussion about them here, so I figured I'd ask: has anyone here worked with Optasy, and what was your experience like? Also, are there agencies anyone else would recommend as an alternative?

We looked into Acquia Technocrat and Lullabot before choosing Optasy, so I'd be interested in hearing thoughts there too. Ultimately, we won't need much from a vendor beyond pushing security updates (which we honestly can do ourselves now).

Thanks!

Hi guys,

I’m trying to track how safely changes are delivered. There are PR reviews for security and best practices, but no full-context checks.

Any useful metrics or automation approaches?

I know automated tests and staging help, but in this project there’s no dedicated QA

Any idea?

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