Today we are talking about The Drupal Developer Survey, Last year's results, and How it helps Drupal with guest Mike Richardson. We’ll also cover HTMX as our module of the week.
For show notes visit: https://www.talkingDrupal.com/493
TopicsMike Richardson - Ironstar Dev Survey richo_au
HostsNic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Andrew Berry - lullabot.com deviantintegral
MOTW CorrespondentMartin Anderson-Clutz - mandclu.com mandclu
Join us THURSDAY, March 20 at 1pm ET / 10am PT, for our regularly scheduled call to chat about all things Drupal and nonprofits. (Convert to your local time zone.)
We don't have anything specific on the agenda this month, so we'll have plenty of time to discuss anything that's on our minds at the intersection of Drupal and nonprofits. Got something specific you want to talk about? Feel free to share ahead of time in our collaborative Google doc: https://nten.org/drupal/notes!
All nonprofit Drupal devs and users, regardless of experience level, are always welcome on this call.
This free call is sponsored by NTEN.org and open to everyone.
Join the call: https://us02web.zoom.us/j/81817469653
Meeting ID: 818 1746 9653
Passcode: 551681
One tap mobile:
+16699006833,,81817469653# US (San Jose)
+13462487799,,81817469653# US (Houston)
Dial by your location:
+1 669 900 6833 US (San Jose)
+1 346 248 7799 US (Houston)
+1 253 215 8782 US (Tacoma)
+1 929 205 6099 US (New York)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
Find your local number: https://us02web.zoom.us/u/kpV1o65N
This past week, the Drupal community was stirred by an open letter from Josh Koenig, Co-Founder of Pantheon, challenging Drupal’s positioning in the modern digital space. Koenig argues that Drupal must move beyond the traditional Digital Experience Platform (DXP) model and redefine itself as an "agile business driver"—a tool that empowers digital teams with flexibility and control without vendor lock-in.
His perspective has ignited discussions on Drupal’s future, especially with DrupalCon Atlanta 2025 on the horizon. Is Drupal evolving fast enough to meet the needs of enterprise users? Should it shift focus to adaptability rather than chasing competitors? These questions are at the heart of Drupal’s next chapter.
Such debates and diverse perspectives are vital for open-source initiatives like Drupal, which rely on community-driven evolution. It is up to the community to pay heed, introspect, and ensure that Drupal continues to thrive—rather than risk fading into obscurity.
Let's have a look at last week's important stories.
Happy reading,
Thomas Alias K,
Sub Editor,
The Drop Times
We just want to take a moment to thank all of the amazing sponsors of the DDEV open source project. All of you reading this know that we've been working for years now to make DDEV a financially sustainable project, so it can serve you into the future. So many have responded to that call. Thank you!
Even though we're going to mention the biggest sponsors first, we want all of you to know that your sponsorship matters too, and with care we can expand to many, many small sponsors to ensure DDEV's resilience and sustainability.
Here are some of many sponsors who help out via GitHub Sponsors.
The open-source community has lots of folks helping out multiple collaborators. In our case, MacStadium provides us testing resources, and JetBrains provides a subscription to their IDE products, thanks!
But we never forget Docker. Docker has adopted us in the Docker-Sponsored-Open-Source (DSOS) program for a few years now, and this means that all of your image pulls are sponsored in that project. You may know that normal image pulls will be strictly limited starting April 1, 2025, but because of the DSOS, users of DDEV won't hit that restriction.
And please don't forget that the open-source Docker project underlies every single Docker provider. It doesn't matter if you're using OrbStack or Lima or Docker Desktop or whatever, they're all built on top of the amazing Docker open-source project.
We recently set up a full updated JSON feed that can be used to see exactly where DDEV's sponsorship comes from and how we're doing. You can see the latest data any day in the all sponsorships feed. And Mark Conroy has built a web component that can be used to show where we're at on any website. Thank you!
We have almost too many ways that you can sponsor, but we want to make it easy for you and your organization.
Is your name or your organization's name missing here? It's easy to get it here. How much does DDEV's support and ongoing maintenance mean to your organization?
(If I made a mistake and left you out, let me know and I'll edit this.)
Do you have questions or want to talk (about sponsoring or anything else)? Contact us! or join us in Discord.
Read moreOver the past few weeks, the Drupal community has been buzzing with discussions about the future of Drupal.
Just recently I read a really interesting blog post found in the Weekly Drop Newsletter called “Say No to Auto-Updates: Why Your Website Deserves Better Than Subscription Overhaul”. I appreciate articles that take a strong stance, and this one certainly does. However, I strongly disagree with its conclusions.
First, to get that out of the way. I actually do agree with two things
But that's where my agreement ends. Many of the points in the article are in what I would call the “general skepticism category”. This is fine, and at this point quite expected. While skepticism is healthy, data and real-world experience tell a different story. So instead of speculating (and me making counter arguments to the article), let’s look at some numbers shall we? I have some numbers. It’s these specific numbers: 3, 8, 58, 9768.
3: My personal and professional experience is with 3 services: Violinist.io, Renovate and Dependabot. For Drupal (and PHP / Composer) updates mentioned in the article I use violinist.io.
8: I have been automating Drupal updates for 8 years.
58: Currently (at the time of writing) I have 58 personal and professional projects running Drupal (Composer) updates automatically. Most of these are automatically merged after passing tests.
9768: Over the last 8 years exactly 9768 commits have been added by an automatic updater to the 58 projects.
Personally, I think the numbers speak for themselves. But let’s put it in perspective- try converting 9,768 commits into billable hours. Imagine the sheer amount of repetitive work automated away. You can speculate all you want - whether automation fails half the time (spoiler: it doesn’t) or if it’s actually a massive time-saver (it is). But at the end of the day, the results are undeniable.
So, while some debate the risks, I’ll be over here letting automation do what it does best - saving time and getting things done. Here is an animated gif from the days from long before all of these fancy package managers and automation tools.
James Oakley
Sun, 16/03/2025 - 18:30
I recently wrote about my experiences migrating this website from Drupal 7 to Drupal 10. In that post I said that I would write separately about my experiences theming the site. This is that post.
I was broadly happy with the look and feel of the Drupal 7 version of the site, so didn't want something vastly different. At the sametime, I wanted to make sure that I was using the most maintainable underlying code, behind what end-users see.
When it comes to theming a site, there is a spectrum. At one end of the spectrum, you build everything yourself. You write the HTML templates, using Twig from Drupal 8 onwards, that the site will use to render the content. You write all the CSS, laying things out, making sure they are responsive and designed for mobile devices first. At the other end of the spectrum, you pull an existing theme off the shelf, like the many excellent ones you can download from the Drupal website. (As I write, there are 3,190 themes on the Drupal website.)
In between those extremes, moving slightly more customised than starting with an off-the-peg theme, you can take an off-the-peg theme and create a subtheme where you tweak the things you want to change. CSS is easiest, allowing you to change fonts, margins, relative sizes, images, colours, and so on. But template tweaks are possible too.
But I'm most comfortable one level further of controlling things myself. I don't like to write everything myself — it's far too much work, and involves a lot of wheel re-invention. But I find customising someone else's theme constrains my ability to get things looking how I want. I've done that in the past, and end up changing colours and typeface but not a lot else; as soon as you want to move content around on the screen, things start to get messy.
So I like to start with a base theme. A base theme is one that does the heavy lifting for you by giving you lots of default HTML and sensible CSS, but that doesn't make assumptions about what you will want to do on your own site.
My dilemma was: Which base theme to use?
Relatively few of the 260 actively maintained Drupal 10 themes are base themes.
Even fewer are stable.
One of the things I've learnt using earlier versions of Drupal is the importance of using themes that are actively maintained and will continue to be so. Too many times, I've customised a theme, only for the maintainer to wander off and stop updating it. I then have to choose a new base theme in order to keep moving through the versions of Drupal core. If I've customised a theme designed as a base theme, it means designing a new theme using that base theme as a starter. If I've tweaked a theme designed as a fully finished theme, it means swallowing the fact that the visual appearance of the site is going to have to change. Neither is great.
For example, in various previous versions of Drupal core, I've used:
You get the idea. Even since Drupal 8, there's been a whittling down. Just looking at themes that say they are actively maintained, and that have security team coverage, there are currently 210 themes that support Drupal 8, 181 that support Drupal 9, 162 that support Drupal 10, and 81 that support Drupal 11. So users of 129 of the 210 themes that support Drupal 8 are not able to move to Drupal 11, and nearly 50 of them can't use Drupal 10 either giving them no supported options. You'll recall that I'm using Drupal 10, not Drupal 11, because there are modules that haven't released Drupal 11 versions yet.
So as far as you can, try to find a base theme that is still being actively maintained. Look to see if code is still being committed. Look for two things in the issue queues. 1. Do the maintainers respond reasonably promptly? 2. Are there issues that have been stuck at "reviewed and tested by the community" for some time? If improvements / bug fixes have been tested, they should either be committed or moved to "won't fix" with a clear reason. Code stuck on RTBC is an amber flag in my book.
I also look for themes that are old. I don't want one that has just had its first release. I look for ones that have been around for several major versions of Drupal core, to demonstrate a maintainer who is active in moving it through the release cycles.
My first attempt was a theme ecosystem named Barrio Bootstrap.
This is a really strong base theme. As the name suggests, it rewrites all of the Drupal templates to work within the Bootstrap framework. It is intended as a base theme. However, as you develop a sub-theme, it will help greatly if you can write your CSS using Sass; you get the benefits of the Sass mixins, you can use variables, and you can nest rules. There is a subtheme of Barrio Bootstrap called the Bootstrap 5 Sass Starter Kit. The maintainers recommend you extend that, rather than Barrio Bootstrap directly.
As I worked on site structure, I used the Sass Starter Kit unaltered. I think it was this that slightly put me off in the end. The fact I was able to use it out of the box means it made a lot of assumptions I'd want things coloured and laid out. As I came to start making the site look how I wanted it, it was harder work because I was editing to change inbuilt assumptions rather than working from scratch. I'm sure it can be quite intimidating to load an unaltered subtheme of a base theme, and to see just black text on white with no margins or borders between elements. However, if you're going to be using Chrome or Firefox developer tools to lay things out just how you want them, that is actually the best way to start and is going to be less work overall.
I was also slightly nervous that Barrio Bootstrap came with some colour editing tools in the UI. It wasn't immediately obvious where the theme saved the resulting CSS, or how that interfaced with the CSS that I had compiled myself from Sass. I found myself wishing all the configuration was in one place. If I was going to design a site myself, I don't want code potentially overwriting the CSS I've written; it could be hard to find where problems are coming from.
My final hesitation was the way it generates two CSS files, one with source links and one fully optimised. Shipping both, and changing which one is loaded in the theme's info file, felt clumsy. I'm sure to other people it feels really intuitive, but it didn't work for me.
So I looked to see what else was out there.
And I found the Radix base theme. The theme has a Drupal project page and a really good documentation site of their own. I am unclear what connection, if any, the Drupal theme Radix has with the wider Radix UI project. I suspect they're unrelated.
Unlike the Barrio family, this theme really is not designed to work on its own. In fact, it won't work properly. The theme ships with a starterkit for a subtheme, and sites will only render correctly if you have the elements from both a subtheme and the base theme in place. So your first step has to be to create your subtheme. Happily there are really good instructions for this on their website. I followed them, and everything just worked.
The more I use Radix, the more I like it as a base theme, and I can see this being my default base theme for future projects. Here are some of the things I like:
npm run watch), then compile in release mode (npm run production) before I commit a series of changes to git. That keeps the git commit noise down, and means staging and production environments only ever pull the production-ready styling.npm run watch, a web server starts running on a port in the 3000s that will render a copy of your site showing the most current layouts. Any time you make a change to the source .scss or template files, the CSS is automatically recompiled and a signal sent to your browser to reload. So you can tweak things like margins and colours and watch the effects in near real-time. I don't develop on my local machine, so I had to open the requisite ports through my development server firewall, but other than that this is a really easy way to work on a site's appearance.As I've built a theme with Radix, I've learnt a few lessons along the way that are worth sharing.
subtheme/templates folder contains a mixture of original and altered templates.subtheme/components folder contains only your alterations.cp -ar ../../config/radix/src/kits/radix_starterkit/templates ./.templates.origcp -ar ../../config/radix/components ./.components.origdiff -urq to compare templates / components in the new Radix version with .templates.orig / .components.orig in your subtheme..templates.orig / .components.orig folders so they're ready as reference points for the next base theme update.templates folder to work out what HTML to render. The templates folder in the Radix theme is intentionally thin; most of the templates simply insert the HTML generated by a component, and let the components folder do the heavy-lifting. This helps keep your theme maintainable. Throughout the templates folder, you'll see code like this: {% include "radix:page-title" %}. That tells the theme engine to include the output from the page-title component within the radix theme.{% include "radix:page-title" %} to {% include "your_subtheme:page-title" %}. As I say, it's easy to forget.Home > Administration > Configuration > Development and check the box labelled "Do not cache markup".drush cr after a template change can help ensure those changes appear on the site.npm run watch, the process seems to read all the files that need watching for changes.Ctrl+C, and run npm run watch again.node_modules, within that is a folder named bootstrap/scss, within that is a file named _variables.scss. At this point grep is your friend. Find the variable you want to change, and go to src/scss/base/_variables.scss within your subtheme. Set the variable you want.<a> tags from underlining. Rather than writing a { text-decoration: none; } in the scss of a component, all I needed to do was enter $link-decoration: none; in my _variables.scss fileOne thing I noticed straight away was that Radix doesn't give you sidebar regions for placing blocks.
I was tempted to feel grumpy and move on to look for another base theme, but then I realised this is deliberate and a good thing. Not every site uses sidebars. So let those sites that want them add them, and let those that don't have leaner mark-up.
It turns out it's easy to add sidebars. Given this isn't a requirement for everyone, but because it will be quite a common wish, I'll write that up in a separate post. Watch this space!
Blog Category: Drupal Planet Add new commentImagine waking up to discover that overnight, AI agents rewrote 500 product descriptions, reorganized 300 pages for SEO, and updated 9,000 alt-text descriptions on your website.
As you review the changes over coffee, you find three product descriptions featuring nonexistent features. If published, customers will order based on false expectations. Then you notice another problem: AI rewrote hundreds of alt-text descriptions, erasing the ones your team crafted for accessibility.
AI-driven content management isn't a distant scenario. Soon, Content Management Systems (CMS) may deploy hundreds of AI agents making bulk edits across thousands of pages.
The challenge? Traditional CMS workflows weren't designed for AI-powered editing at scale. What features should an AI-first CMS include? What safeguards would prevent errors? What workflows would balance efficiency with quality control? I'm outlining some rough ideas to start a conversation and inspire Drupal contributors to help build this future.
AI-generated content needs different quality checks than human work. Current editorial workflows aren't optimized to handle its output volume.
I envision "AI review queues" with specialized tools like:
Say an AI translated your site into Spanish with mixed results. Meanwhile, editors updated the English content. Without sophisticated versioning, you face a tough choice: keep poor translations or roll everything back, losing days of human work.
CMS platforms need Git-like branch-based versioning for content. AI contributions should exist in separate branches that teams can merge, modify, or reject independently.
AI isn't just generating content. It is also modifying site configurations, permissions, content models and more. Many CMS platforms don't handle "configuration versioning" well. Changes to settings and site structures are often harder to track and undo.
CMS platforms also need Git-like versioning for configuration changes, allowing humans to track, review, and roll back AI-driven modifications just as easily as content edits. This ensures AI can assist with complex site management tasks without introducing silent, irreversible changes.
Standard CMS audit logs track who made changes and when, but AI operations demand deeper insights. When multiple AI agents modify your site, we need to know which agent made each change, why it acted, and what data influenced its decision. Without these explanations, tracking down and fixing AI errors becomes nearly impossible.
AI audit trails should record confidence scores showing how certain an agent was about its changes (60% vs 95% certainty makes a difference). They need to document reasoning paths explaining how each agent reached its conclusion, track which model versions and parameters were used, and preserve the prompt contexts that guided the AI's decisions. This comprehensive tracking creates accountability in multi-agent environments where dozens of specialized AIs might collaborate on content.
This transparency also supports compliance requirements, ensuring organizations can demonstrate responsible AI oversight.
AI needs a governance layer to ensure reliability and compliance. Imagine a healthcare system where AI-generated medical claims must reference approved clinical studies, or a financial institution where AI cannot make investment recommendations without regulatory review.
Without these guardrails, AI could generate misleading or non-compliant content, leading to legal risks, financial penalties, or loss of trust.
Instead of just blocking AI from certain tasks, AI-generated content should be checked for missing citations, regulatory violations, and factual inconsistencies before publication.
Implementing these safeguards likely requires a "rules engine" that intercepts and reviews AI outputs. This could involve pattern matching to detect incorrect content, as well as fact verification against approved databases and trusted sources. For example, a healthcare CMS could automatically verify AI-generated medical claims against clinical research databases. A financial platform might flag investment advice containing unapproved claims for compliance review.
I can't predict exactly how these ideas will take shape, but I believe their core principles address real needs in AI-integrated content management. As AI takes on a bigger role in how we manage content, building the right foundation now will pay off regardless of specific implementations. Two key investment areas stand out: