Hey everyone,

I was recently looking into better ways to handle theme configurations without having to hardcode everything or constantly hit refresh, and I stumbled on this walkthrough for Space DS 2.x (Space Design System).

It looks like they’ve added a really smooth live preview directly in the admin panel. You can toggle dark/light mode, swap device views, and tweak typography/colors with real-time updates—no saving and reloading required.

A huge plus for me is that it has native Storybook integration for SDC (Single Directory Components). I know getting Storybook to play nice can sometimes be a headache, but the props and dynamic slots seem to map over perfectly here. They also showed off their Lighthouse scores in the video and it's pulling a 99 on mobile, which is pretty sweet.

Anyway, I thought it was a really neat approach to bridging the gap between the admin UI and the frontend. Figured some of you might find it useful if you're building out landing pages or managing complex themes.

Here’s the walkthrough if you want to see the UI in action: YouTube Video Link

Has anyone used this (or a similar setup) in a production environment yet? Curious to hear how it scales!

A patch is in the works: https://www.drupal.org/project/drupal/issues/3592065

[ Removed by Reddit on account of violating the content policy. ]

Upgrading a Drupal 10.4.x installation via composer has resulted in this bootsrap error.

PHP Fatal error: Type of Drupal\shortcut_menu\ShortcutMenuLazyBuilder::$entityTypeManager must be ? Drupal\Core\Entity\EntityTypeManagerInterface (as in class Drupal\shortcut\ShortcutLazyBuilders) in /var/www/html/web/modules/contrib/shortcut_menu/src/ShortcutMenuLazyBuilder.php on line 9 

drush cr, drush cc drush upgradedb:status and drush pm:uninstall all fail because of

How can I disable it?

Can I use composer to do it, or will it be better to disable it by setting the value in the system table or some other table that disables the module?

Does the latter method work for the Drupal 10+ series?

We once had a consultation with a Drupal Agency when we moved from D7 to D9. They explained to us that "blt artifact deploy" can be used to fill a git repository that is then copied to the server for hosting using CI/CD.

With BLT not being maintained anymore, what's the successor for this kind of workflow? Is there a replacement to handle this? Should it be done on a per project basis and artifact deploy isn't a valid approach anymore?

Would like to get some insight on how others do this and appreciate any feedback or hints to tooling or workflow to learn.

As the subject says, I'd love to edit some theming colors to recreate an old site stuck at Drupal 7, the theme itself is Bootstrap Business and while this was part of the theme back in the day those options no longer exist in the current version for D11

What is the best/recommended way in 2026?

Is there a call for passwordless login via an emailed access code?

I've recently implemented the passwordless module (https://www.drupal.org/project/passwordless) on a site which utilises the core reset password functionality to log users straight in via unique login link.

The negatives are a user wanting to access a page via an external link that they need to log in to view, the page they want to access is lost in the process of receiving the email and clicking to log in. With an extra page with an access code form the user can then navigate to the page they want. Or is this niche? Or have I not found and implemented the correct flow/configuration?

Any feedback or advice is appreciated 😄

I just run this command I didn't see any drupal/core-xxxx packages in the listing.

The disk was running out of space and saw the message in the admin that I didn't have enough space, ie 1024k to upgrade Drupal core and wonder if that was why the above command didn't upgrade Drupal core as well.

I upgraded it using composer require drupal/core-recommended:11.1.10 drupal/core-composer-scaffold:11.1.10 drupal/core-project-message:11.1.10 --update-with-all-dependencies

It was as far as I could go probably it was a Drupal CMS 1.0 installation.

CISA added CVE-2026-9082 to the KEV catalog yesterday (May 22). For those catching up: this is an unauthenticated SQL injection in Drupal Core's database abstraction API that affects PostgreSQL-backed installs. There's working PoC code from Searchlight Cyber already in the wild, and SecurityWeek confirmed attacks on thousands of sites.

The technical detail that I think is being undersold in the mainstream coverage:

The flaw is in the code that's *supposed to prevent* SQL injection. The Drupal database abstraction API is used precisely to sanitize queries before they hit PostgreSQL. A user-supplied PHP array key reached the SQL placeholder construction stage without being stripped. The patch is an `array_values()` call that resets array keys to sequential numerics before they can do damage. It's clean and correct — but it took a disclosure for anyone to notice the gap.

The thing I'm curious about from people running Drupal in enterprise environments: **are you treating Drupal's pre-announcement PSA (published May 18, three days before the actual advisory) as enough lead time to get patches through your change management process? Or is the 24-72 hour window still too tight for your approval workflows?**

I ask because that gap — between when you can prepare and when the PoC drops — is increasingly the only window defenders actually have.

---

I previously covered a similar platform-layer trust failure in the CVE-2026-41940 cPanel Authentication Bypass if you want background on how attackers operationalize these types of vulnerabilities: https://www.techgines.com/post/cve-2026-41940-cpanel-authentication-bypass-zero-day

Full technical breakdown with patch table and exploit mechanics: https://www.techgines.com/post/cve-2026-9082-drupal-sql-injection-postgresql-rce

Not looking to just drop a link — genuinely interested in how people are managing the patch urgency vs. change control tension here.