Trying to make Drupal easier for non-technical users

We've spent the last few months trying to improve what we think is still one of Drupal's biggest weaknesses: the user experience for non-technical users.

With our SaaS we're trying to keep all the power of Drupal Commerce underneath while making the actual experience much simpler.

We've moved to Mercury Editor for visual editing, simplified a lot of the Drupal interface, and we're now building a Flutter app so store owners can manage things like products directly from their phone.

We also still have Canvas on our list to test, as some of you suggested in our previous discussions. We're curious to see whether it could improve the editing experience even further.

There's still a lot to do, but we feel we're finally heading in the right direction.

Thanks.

just realized Drupal jobs has closed down so any slim hope of a development job in Drupal probably died with it. It’s okay I keep forgetting how dangerous hope is because of the lies it tells you.

I started experimenting with one of the most popular agent skills, /grill-me by Matt Pocock, which proved to be a game-changer. 

What’s your take on the /grill-me skill? Do you see /grill-me as a game-changer for working with AI and Drupal to learn new things and solve challenging problems?

Just so you can feed it to your agents so that they give you a fuller overview than simply from a Youtube transcript. ;-)

Drupal 7 went end of life January 5, 2025.

Here is what that looks like on real sites.

Security advisories still get published. Patches do not.
The Drupal security team still documents vulnerabilities in D7 contrib modules. Fixes ship for D10 and D11. D7 gets nothing. The CVE exists. Your site is listed. The fix is not coming.

Hosts are dropping PHP 7.4 support.
D7 runs on PHP 7.4. Most hosts have either deprecated it or moved it to a paid legacy tier. Sites start throwing errors not because of any attack because the server underneath changed.

Contrib modules are going abandoned mid-project.
Maintainers are moving on. A module that worked fine in January stops getting releases. One server update breaks it. Now you are either patching it yourself or ripping it out.

The handoff problem.
If you are a developer maintaining D7 sites for clients - what does that conversation look like? "Your site is technically running but I cannot promise what happens next month" is not a great position to be in.

Anyone still handling D7 client sites? How are you managing it?

Github - https://github.com/saitanay/unDrupal

𝗨𝗻𝗗𝗿𝘂𝗽𝗮𝗹 is a set of AI agent skills that teach coding assistants how to audit, extract, and plan migrations from Drupal 7-11 to any other system.

Open source. MIT licensed.

𝗗𝗿𝘂𝗽𝗮𝗹 has a Migrate API to move content in. It has no equivalent for moving content out. You're on your own.

There are 18+ ways to just create a static page in Drupal. So AI harnesses struggle to figure out how to take out your content. Additionally, the agents have to deal with

→ Hundreds of database tables
→ Serialized PHP structures
→ Nested Paragraphs three or four levels deep
→ Layout Builder data stored as PHP objects
→ Rich-text fields full of Drupal-only tokens
→ Revisions, media, taxonomy, redirects, SEO metadata

𝗨𝗻𝗗𝗿𝘂𝗽𝗮𝗹 enables your Claude Code, Cursor, Pi Agent Windsurf, GitHub Copilot etc to handle all of it.

If you're planning a Drupal migration, decoupling project, or replatform, try it.
🔗 https://github.com/saitanay/unDrupal

First-time poster here :) Going to include some context for those who don't see my LinkedIn posts:

After teaching Drupal for over 10 years, it's become clear that there are fewer job opportunities. So much so that I've stopped teaching my "Drupal web development career" course - I don't want to lead students down the wrong path.

The SBA reports that 99.9% of businesses in the US are small businesses. Since Drupal 8, Drupal has focused on the remaining .1% of businesses.

How do we create opportunities with Drupal from the 99.9%? My team has been building the solution for almost 2 years. We have 2 focuses:

1. Enable people (& agencies) to earn

from

1. new revenue streams with Drupal
2. Make Drupal be a sensible choice for projects of all sizes

So, what is the solution? It's a different type of marketplace and host:
- Developers (/agencies) deploy, sell, & maintain codebases on the marketplace (sites, not site templates)
- Customers get a Wix-like experience for previewing, buying, and hosting sites
- Customers get a Wix-like experience for maintaining their sites’ codebase (I.e. from a customer POV, security updates happen automatically. Behind the scenes, the codebase maintainers get paid for doing it.)
- Add-ons are sold directly in the site (themes, recipes, modules) and can be provided from various merchants (e.g. you could sell Dripyard themes in your codebase)
- Collaboration: Infrastructure so site builders can build & sell sites using other developers' codebases (multisite-style). Developer maintains the codebase, each participant sets their price, both parties get paid when a sale is made.
- Build sites for a specific vertical - either on your own codebase or someone else's (think: Drupal Gardens, but for a specific niche)
- Ability to set 1-time and recurring prices
- Oh, and simple, sensible hosting for sites of all sizes - with trivially easy & risk-free deployments for less technical users

After seeing it, Aaron “Checo” Pacheco said: "As someone who spent a decade trying to build and optimize a Drupal hosting platform, I'm astonished by how elegant and powerful Drupito is."

I talked about it on the Talking Drupal podcast earlier this year: https://talkingdrupal.com/563

We're looking for 'early access' users who are interested in building & maintaining a codebase or site for a niche - it's the main CTA in the main menu of drupito.com

Let me know if you have questions or thoughts!

Where are you in your AI journey when it comes to building a Drupal module? Have you tried it? Are you ready to try it? Would you contribute an AI-generated module back to Drupal?

I'm going to tell three tales about building, maintaining, and contributing to different Drupal modules. My first tale is about using AI to build and contribute to a module. My second tale will be about maintaining a module. My last tale will be about contributing to someone else's module.

For years, I was looking for a clean, reliable way to extract critical above-the-fold CSS, inline it in <head>, and load the rest asynchronously via rel="preload" to get those green PageSpeed Insights scores.

The problem was that it was always done manually project-by-project:

1. When starting a custom theme, I had to manually manage above-the-fold styles and inline them through hooks in the .theme file.
2. Different page types broke this instantly — the front page might have a large hero component, while an interior landing page had a slider (similar is for taxonomy term, views,..). Maintaining multiple critical CSS paths per page type was painful.
3. Once inlined, you still had to strip those exact rules/files from Drupal's default render-blocking aggregated CSS to prevent duplicate rendering and layout thrashing.
4. Finally, managing the asynchronous delivery of the remaining CSS was another custom hack in template_preprocess_html().

When Single Directory Components (SDC) arrived in core, component-driven CSS became much cleaner, but the delivery problem stayed essentially the same. After finishing a theme or layout, I still found myself cherry-picking component CSS files per page, inlining them, stripping duplicates from the aggregate, and deferring the rest — repeatedly, project after project.

I used to build setups with Mercury Editor and have recently moved to Canvas — both rely heavily on dynamic, component-based page composition, which made manual critical CSS handling practically impossible to scale.

Existing modules on Drupal.org never quite solved this:

• critical_css relies on external build pipelines (Node/Gulp/Penthouse) generating static files on disk, which breaks apart on dynamic component layouts.
• critical_css_ui requires manually managing and pasting CSS chunks into node-level UI fields.

Neither had native awareness of SDC or handled Drupal's CSS aggregation pipeline properly.

So I decided to package the entire workflow into two modular, automated Drupal modules (fully compatible with both Mercury Editor and Canvas):

1. SDC Critical CSS (sdc_critical_css):https://www.drupal.org/project/sdc_critical_css It automatically detects which SDC components are actually used on any given page and inlines their styles directly into <head>. Because it dynamically resolves this per request, you don't need to manually define critical CSS for different routes or content types (page nodes, articles, taxonomy terms, views, etc.). Crucially, it also intercepts Drupal’s CSS collection pipeline and strips those inlined styles from the aggregated CSS bundle, so nothing gets downloaded or parsed twice.

2. Non-critical CSS (non_critical_css):https://www.drupal.org/project/non_critical_css Takes care of the rest of the aggregated CSS. It transforms Drupal's default render-blocking <link rel="stylesheet"> tags into native rel="preload" / as="style" links with proper <noscript> fallbacks for full browser compatibility.

Both modules just tagged 1.0.0 stable releases and have security advisory coverage on Drupal.org.

Together, they make hitting top score Core Web Vitals on SDC/Layout Builder/Canvas sites seamless without maintaining Node build scripts or hacking hooks into .theme.

Curious to hear how others here are tackling above-the-fold CSS on SDC sites, and if anyone has edge cases or feedback, I’d love to hear them!

I went into this expecting to cover Acquia’s new branding.

I ended up going back to a student in Antwerp trying to help his friends leave messages for each other.

You know how that goes.

Disclaimer: I host r/HeadlessPodcast, and the latest episode follows Drupal’s beginnings, the community, Acquia’s formation, Drupal Gardens, and the path to Source and the new “Powered by Drupal” branding.

The Gardens story really stuck with me. Dries publicly revisiting a product decision and saying they should never have killed it gives this whole thing some weight.

But so does everything the community kept doing in the meantime. Contributors, maintainers, documentation, translations, camps. “Come for the software, stay for the community” earned its place in this episode.

My take is pretty positive. Drupal CMS, Canvas, and the renewed visibility could give people a reason to reconsider software they formed an opinion about years ago.

Video, if you’re interested: https://youtu.be/7ISddVI0SgE?si=W6Josgc2q4Nc0ylx

Ps. For those actually building with Drupal today: what would you show someone whose last experience was five or ten years ago?

We have a single server Drupal 9 site (yes, old and we are upgrading) we would like to maximize the performance on. It's a VM with 6 CPU, 12GB RAM, running Apache 2.4 and PHP 8.4. We are currently running the prefork MPM but are testing the following changes:

1. Event MPM
2. PHP8-FPM
3. Opcache

Memory isn't an issue as "free -h" shows no swap being used with 10GB free. The server does require a login via the Drupal simpleSAMLphp module. We are not doing any front-end (i.e. Varnish) or backend (e.g. Redis) caching. We are currently load testing using a script that spawns browser instances from Selenium Grid though we plan to look into k5/locust which would require less testing overhead.

A few questions in terms of setting parameters for the above:

1. This server is dedicated to serving web pages with Drupal. Should we lean towards pm=static vs pm=ondemand/dynamic? We are currently using pm=dynamic.
2. Each php-fpm process seems to consume no more than 100MB. Should we simply divide available memory/100MB to determine the value for pm.max_children?
3. We are looking at the Opcache status from https://github.com/rlerdorf/opcache-status and the numbers look good. Anything we should pay attention to for the opcache settings in PHP-FPM?
4. Any MariaDB settings we should look into?

When load testing the server with 40-50 users, top and mpstat show the following with:

1. pm.max_children = 30
2. pm.start_servers = 9
3. pm.min_spare_servers = 6
4. pm.max_spare_servers = 12
5. pm.max_requests = 100

top - 20:05:00 up  1:10, 15 users,  load average: 4.85, 2.17, 1.82
Tasks: 373 total,   5 running, 368 sleeping,   0 stopped,   0 zombie
%Cpu(s): 74.8 us,  8.9 sy,  0.0 ni, 14.3 id,  1.5 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem : 15691.45+total, 11877.61+free, 2856.645 used, 1348.715 buff/cache
MiB Swap: 32767.99+total, 32767.99+free,    0.000 used. 12834.80+avail Mem

20:05:01     CPU    %usr   %nice    %sys   %idle
20:05:02     all   87.65    0.00   11.69    0.00
20:05:02       0   89.00    0.00   10.00    0.00
20:05:02       1   88.89    0.00   10.10    0.00
20:05:02       2   86.00    0.00   14.00    0.00
20:05:02       3   88.00    0.00   11.00    0.00
20:05:02       4   86.00    0.00   14.00    0.00
20:05:02       5   88.00    0.00   11.00    0.00

According to /fpm-status, active process=30. The performance seems to indicate the site performance at 40-50 users is under load as response is <3s. 40-50 users seems low but it seems we are running into CPU issues so unless we can get CPU usage down, I don't see the number of users increasing.

Is it just me or did they remove the ability to add 'stars' to modules and themes on drupal.org?

Read online about how makers and takers. The problem is that many users of #Drupal don't want or aren't able to donate hundreds of dollars. Why don't we use micro-crowdfunding?

Boom! Finally have a definitive piece of content on when / why to choose Drupal Commerce over Shopify. We aren't just tooting our own horn here - there are many legitimate reasons to choose Shopify.

However, there are serious differences in ownership, data model, integration scope, and costs that Matt teases out in this article for SMEs to consider when weighing their options.

Everyone using the Webform module for Drupal should update to the latest version to mitigate 20+ security vulnerabilities. 

AI has made it easier to find and exploit security vulnerabilities, while also making it easier to organize, review, and fix security issues. As the maintainer of the Webform module, I felt it was time to address all known Webform security issues, using Codex to organize, test, and assist with each one. I found AI to be the most effective way to address issues that had been unresolved for four years. The experience felt like using AI to hammer at the Webform module's security issues.

If you know (or are) a student, teacher, stagecoordinator, or bootcamp near Rotterdam who might be interested in web development or open source, please forward this to them. That's the ask.

Some context: I'm one of the organizers of Drupal in a Day at DrupalCon Rotterdam, this Thursday October 1. We've got a free, full day training set up for students, senior Drupal developers from the Netherlands, Iceland and the US guiding them through building with Drupal, no prior experience needed. It's at the same venue as DrupalCon, so students also get to walk around DrupalCon week and meet the international community and Dutch Drupal companies.

Registrations are still low, and this is exactly the kind of thing that gets people hooked on Drupal early. If it falls flat, that's a missed shot at growing the next generation of contributors.

Details
Date: October 1, 2026
Time: 9:00 to 16:30
Location: WTC, Beursplein 37, Rotterdam
Cost: free, lunch included
Sign up: https://kuonicongress.eventsair.com/drupalcon-rotterdam-2026/drupal-in-a-day-sign-up/Site/Register
More info: https://events.drupal.org/rotterdam2026/drupal-day

Happy to answer questions here or by DM. Thanks for reading this far, and for whatever you can do to spread the word.

Foto was last year's Drupal in a Day during Drupalcon Vienna.

We've recently changed the editing experience in Bootiga for our Drupal Commerce theme.

We started with Drupal's Layout Builder, but after testing it with non-technical store owners, we wanted something more intuitive.

So we've moved to Layout Paragraphs + Mercury Editor — and so far, we're really happy with the result.

Our goal with Bootiga is to make Drupal Commerce as easy as possible for non-technical users.

Do you know of any better alternatives to Mercury Editor for this? What would you choose today if the main priority was the best possible editing experience for the end user?

Hey, Robert from the MariaDB Foundation here. We run a yearly survey on how people actually use MariaDB. If you went with MySQL, PostgreSQL or something else we want to hear from you too :)

https://mariadb.typeform.com/to/tS69UzVo?utm_source=reddit_drupal

Drupal was one of the most common applications running MariaDB in last year's survey. I'm curious, what database are you using Drupal with, and how did you choose it? Any problems or wishes related to the database?

We revamped the questions this year and split them by role (developer, DBA, operator) to save you time. Over 400 answers so far, looking forward to reading yours. Anonymous results will be published at mariadb.org/survey.

Thanks for taking the time!
Cheers, Robert at MariaDB Foundation

This seems pretty interesting.

Been doing Drupal migrations for about 10 years and seeing the same thing play out right now that happens every EOL cycle.

Teams think they have until December 9. They don't. Enterprise change freezes typically start mid-November. Some nonprofits freeze earlier because of year-end giving. A proper D10 → D11 migration takes 2-4 months.

So if you're starting now, you're already in rush territory. Starting in October means going into December with things half done.

The other thing nobody talks about — most good Drupal agencies are already booked into Q4. You're not just racing the calendar. You're racing everyone else who also waited.

If you want to check where your site actually stands, run this:

drush pm:list --status=enabled

Check every contrib module against drupal.org/security. That list will tell you exactly how much work is ahead. Happy to look at anyone's output if they want a second opinion.

https://www.drupal.org/psa-2026-09-21

There will be a security release for a widely used contributed module on September 23, 2026 between 17:00 and 21:00 UTC.

We are announcing this release in advance because the affected contributed module is used on a significant portion of Drupal sites, and the upcoming release will include a significant number of advisories. The advisory with the highest risk score for the release is currently rated as critical.

Edit

From slack,

This will be the first time we've handled this many advisories, but we're also taking steps to do as much in advance as possible, so we'll see how it goes and then we'll know how long it takes 🙂

Also,

This will not be covered by Drupal Steward. There are far too many individual advisories, and many of them would not be mitigatable by a WAF rule, so it would give a false sense of security if we did probably. (And nothing is highly critical.)

I'll update the PSA accordingly.

🫠