Hello author here!

What is DruBOM: a Drupal module that lists every component a site uses, checks for known vulnerabilities and exports an SPDX 3.0.1 SBOM, requiring no third party libraries installation.

In this post I outline what the module does, how it has improved and how it was built; I hope you enjoy the post and the module, and feedback is welcome.

https://www.paolomainardi.com/posts/drubom-next-gen-drupal-supply-chain-security/

If your site uses Field UI in drupal/core, this week's advisories include a remote code execution vulnerability in that module. It isn't directly exploitable with core alone, but I'd still check your installed version.

The fixes are in 10.6.19 / 11.3.19 / 11.4.10 / 12.0.0-beta2, depending on your branch. Those releases address all three core advisories:

• drupal/core, Field UI: remote code execution, with the core-alone limitation noted above.
• drupal/core, Link: insufficient sanitization of certain markup.
• drupal/core, Navigation: insufficient attribute sanitization that can lead to cross-site scripting (XSS).

I read the new Composer advisories each week. For the week of 12 October 2026, these are the ones I'd check first on Drupal sites.

Full list with advisory links: https://patchclock.com/security-digest/2026-w42?utm_source=reddit

Disclosure: I build PatchClock, a CRA compliance tool for PHP vendors. The weekly list itself is free.

When I started my postion as a Drupal Web Developer I inherited a very poorly maintained Drupal site. It was on Drupal 9 when I started, a week before it went EOL. It took me a year to clean it up enough to make the jump to D10, and that was with a lot of help from my predecessor, who we had to bring in on a consulting fee, and while he was great and wicked smart, he was not a great teacher. I've been in my position for 3 years and have been so bogged down in front end content management that I haven't had time to do anything other than regular D10 patches. Now we're looking to jump to D11, since D10 is going EOL, and this new PHP nonesense is driving me up the wall trying to figure out how to fix all this without torching the site.

At this point I'm looking for a company who can come in and clean up all the wonky database mess we have, figure out what packages are being used, and basically clean up the back end of the site so I can have a clean build to work with. Who can I reach out to for a consultation and figure out how I can get this site back to a manageable build?

At Kitchener Public Library. I'll be speaking on the Hosting Panel, so I hope to see some of you there! 😄

I took a closer look at Drupal’s market share, the Drupal 7 to Drupal 8 transition, the developer ecosystem, and how its CMS and AI capabilities compare with WordPress and other platforms.

The numbers raise some important questions about the cost of breaking changes, developer experience, ecosystem maturity, and whether new initiatives are addressing the challenges users actually face.

This isn't just about Drupal vs. WordPress. It's about what happens when a platform's evolution starts moving away from the needs of its community.

I’ve put together a detailed, data-backed analysis here 👇

https://tanay.co.in/blog/drupal-is-not-light-years-ahead

Curious to hear from developers, agencies, and businesses that have worked with Drupal: Does its reputation still reflect the reality of using it today?

I (non-technical) recently stepped into a leadership role at my company who is on an old Drupal 7 site running php 7.4.9. My lead developer said the fix issued for php2shell is not compatible with our old version of php and Drupal 7. He recommended taking down our website until we can upgrade to a newer version of Drupal… which would take a long time, and essentially would kill our business…. We did edit our WAF rules to help prevent cyber attacks but would appreciate any perspectives here and if anyone is in a similar boat.

I can't load drupal.org for the last few minutes. Some pages have been unavailable longer than that. Most of the down detectors say it is still up, but not for me. I am in St. Louis.

Anyone else seeing this? Thanks.

A year ago, I attended a one day drupal training camp and met a few absolutely wonderful people.

So encouraging and just consistently hyping me up any time I got stuck. I tried to download the cms on my chrome book with Linux emulated and forgot to give it enough disk space and they didn't let that keep me behind.

They instead introduced drupal forge to me and made sure I left with some knowledge which I can't thank enough.

However, icl I kinda got lost and could not learn any more cause the difficulty increased tenfold so I never picked it up again but, I'd really like to learn it purely to make my, one day, mentors proud💚

I am running two docker services that use the same Drupal instance.
The first one, let's call it "http", serves the site, and the second one, let's call it "amqp" runs a drush command that listens to AMQP messages (via rabbitmq) to alter content.

The amqp service process tasks that outlive a normal request; a task can take up to several minutes.

I am experiencing cache issues between both services: when a configuration is updated on the "http" service, the "amqp" service still uses a cached version, and when an entity is updated on "amqp" service, the "http" service still shows the old cached version.

I managed to fix the first issue by calling "ConfigFactory::reset" before retrieving the config object when a new message is processed, but this seems like a dirty fix, and I don't see how I can apply such a fix for the issue regarding entities.

Has anyone experienced such an issue ?
Any ideas of how to deal with this ?

P.S: I have APCu and memcache enabled, but the issue appeared before memcache was installed.

Any help will be highly appreciated.