A lot of developers got burned by Drupal in the 2010s. "The drop is always moving" may be gone, but having to do a massive rewrite of a site's template every couple of years and rebuild its plugin ecosystem—even if all one wanted was a secure site—was a lot to manage. Add to it a community that was oriented toward only listening to folks who contributed to the project or made plugins and the bad reputation was earned. I'm not a professional web developer, but I know a few who gave up on Drupal during this time, just as I did. My nonprofit now runs on Wordpress, which isn't perfect, but can handle 1,600 paid members (via a paid plugin) and just works from day to day. My personal site is vastly more sophisticated than it ever was under Drupal since the maintenance is so much less. It's going to take a lot to rebuild this reputation. A lot of love was lost.
yeah, that's the double-edged sword. Drupal can do what it does today because it continually rebuilt it's foundation - but at the same time that sort of movement did cause a lot of pain along the way. At the same time, in the world of "I'll just have my agent rebuild it" makes that sort of change a whole lot easier to deal with - if not the standard everyone may need to adopt.
Drupal earned that reputation for so many architectural upheavals and pointless version churning. I grok innovation, but one of the core properties of web infrastructure is that it's relatively (in a software sense) architecturally stable. Drupal was not that.
It isn't quite as bad as when the codebase was switched to Symfony, but the Drupal project has just kind of abandoned it's core presentation system in favor of the new Canvas tool, and compatibility with the rest of the core seems like an afterthought. So now you have at least 3 competing display configuration solutions, which don't necessarily work together, or entirely work alone.
It's a situation entirely inline with Drupal's reputation: they couldn't just get it right, and now serious Drupal teams don't know which way to go in the ecosystem.
Using Claude to build things quickly is great - but once you hit a certain level of scale, or have a need for governed workflows & oversight, you're more or less going to want some sort of CMS. When that happens, you can either go it alone, or build on top of a lot of well discussed well thought through solutions to these sorts of problems that the Drupal community has dealt with for a couple of decades.
>You can just Claude Code all kinds of shapes of software.
Drupal is used at large organizations with hundreds of sites, thousands of users, and multiple more-or-less coordinated development teams. It's actually a great target for agentic coding, because it has such a well-established internal API. It can definitely feel like an anachronism, but I think there are few projects that could replace some of it's use cases. It's the B-52 of CMSs.
not a whole lot of documentation, I feel like a lot of knowledge is held within orgs. At my first job I often had to venture into the source code to figure out how something is supposed to work. Copilot has just came out then and it was terrible at helping with a Drupal 10 migration for example because the training data only had 8 and below and a lot of stuff obviously changed in-between.
I reckon AI must be much better now at this since it's doing all sorts of things, but I wonder if you still would need to have the repo cloned so that it can crosscheck with the source code. Since the knowledge cutoff should be around 2025, most of the stuff it knows should be plenty
This is how I view it. If you're going to be hosting dozens or hundreds of sites having a consistent platform like this is important even if Claude Code is doing all of the implementation work. It has understood and workable flows for things like content approval, timed releases, etc. All the things people think about when they talk about "managing content" and for the most part organizations still want human in the loop, especially for gated approvals and auditability.
If I'm thinking of building a single one off site, then yeah I'd probably opt to just let CC handle it without worrying about a framework which is overengineered for my current need. That's what I do with most of the personal projects I work on these days. But I do have a skill to build consistency around the parts that should be consistent for everything I host. Like package shape and types of hooks available for deployment. How sites are publicly exposed and DNS management.
One of the best things about Drupal (years ago, when I used to write plugins and themes), was that you could completely customize the backend, as well as the frontend, and that was a good thing, if you have low-tech users that author content. I despise having to walk people through WordPress' backend.
But that rewriting the base system, every couple of years, was why I dropped it.
Nowadays, with LLMs, it may be time to look at it again...
I'm partial to Drupal because I use it a lot - but if you have a large team with a lot of rules around content and making a mistake is a big deal - you don't want to re-invent the wheel with CMS-like functionality.
Remember a while back when the world first heard about Mythos because there was a mismatch between what the "CMS" said was publish, what was shown on the site, and what was "really" available? Those types of problems haven't gone away and if anything are more critical when an army of agents will seek out and find any but of information they can get their hands on.
Not a best reason, but the reason is often because, in the enterprise, marketing hired dozens of people between 2018 and 2023 from the same handful of Drupal consultancies.
> React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
Ok. As someone who hasn't shipped a Drupal site since halfway through the D8 cycle: is this better or worse than the tumor that is Gutenberg?
Drupal made me care about abstraction with every feature in any language I worked with. Drupal made me faster by being a little slower. While working with teams where people were doing one off solutions as fast as they could, I never painted myself into a spaghetti code corner.
There isn't a day I don't ask Claude "What would Drupal do?"
I would not be surprised if approaching vibe engineering from the Drupal perspective is the way out of AI slop.
Nonetheless, although I had a blast one evening building custom modules using Claude wishing I had this tool during those hours of stress I suffered 15 years ago, I don't think there is a place for Drupal outside of higher educations marketing.
I will say, I liked Drupal more than I expected to the last time I used it. But... it's still Drupal.
It feels dated. Even the "new" designs they're rolling out still feel old. They're working with a dated design system, and honestly, it feels like they had developers build it without bringing actual designers into the process. The result is always functional, but somehow a little awkward. Not unified. There's still like 3-4 different ways to do the same sorts of actions depending on where you are. It's clumsy. It's Drupal!
And true to its roots, Drupal still requires way too many third-party modules to get a build working the way I want. Half of those don't even have the "new" design system applied. So even for a CMS that cares about WCAG, they're still falling short. I'm not sure they'll ever get all the open-source developers on the same page. (I know they have a stated goal of 2027... I don't see it happening.)
More broadly, I don't have much confidence that Drupal modules will be maintained beyond a version or two. That makes anything you build on top of them inherently disposable. Which is fine; a lot of the web is disposable. But it also means I don't want to take ownership of long-term maintenance for projects built on Drupal.
Every time I have to install a third-party module in Drupal, I cringe a little. I know that two or three years down the road, when a new major version comes out, I'll be hunting down the guy who wrote the module, hoping he'll update it. Otherwise, we're forking his repo and taking responsibility for maintaining it and applying security patches ourselves. Cringe.
Meanwhile, I've really enjoyed working with Contentful, Directus, and even Statamic. There are a lot of great CMS options out there these days.
One platform I'd actively warn people away from, though, is Strapi. I've had two false starts with projects where people wanted to use it, only to run into some fundamental flaws.
Like, "Oh, you want to associate one of your 10,000 files with this page? Sure, we'll put them all in a dropdown for you to sift through... and that'll make pages take 2 minutes to load." Cringe. Run. (Ha, wait... and the whole, "We are in France, so we don't answer support emails in August." Literally what their support email told me. Yikes.)
In the last five years, Strapi is the only CMS I've built with that I just couldn't get behind on any level. I would have rather used Drupal for those projects. Ha!
Drupal CMS is working to solve some of this - from better designs to confidence in the choice of modules. Any truly open and free choice is going to have this sort of concern though - but unlike a closed ecosystem, at least you do have a choice or path forward when the situation arises.
The problems agents bring to the table are the same problems that UGC brought to the table - new scale, untrusted users, an increased need for governance.
From a user experience perspective:
You can't ever really know if it's a human, an agent, a human driving an agent, or an agent driving a human - so stick to information architecture and accessibility best practices.
beyond that though, we're in new territory when it comes to change / scale / security / etc, so if there is a strategy it'll be out of date tomorrow.
It's too late. Drupal 6 turned me off ever using a CMS again. Now I purely use html files in folders with other files in folders. It's great. No maintainence burden, no attack surface, no resource eating always running programs or database that can get corrupted or otherwise in a bad state. And especially no migrating to the new version and everything breaking (especially with non-core stuff).
Yes, usually when you have a team and need governance over users / content / state. i.e. a publishing workflow that might have specific regulatory review requirements etc.
We're finding that this is becoming even more critical when users are using agents and the scale of changes / publishing increases. Pair that with things like AI regulations that require records of human providence etc, and a CMS becomes even more important.
In my experience, unless your non-dev CMS contributors are strictly filling in blanks with text (sometimes not even then), much of the work ends up delegated to the devs anyway. They are much better off working on a static build that deploys from CI pipelines in gitlab/github.
The benefits are massive ranging from better versioning, free choice of any tools under the sun, strict access control far away from people who don't even understand text encoding, clean CDN deployments, complete elimination of clunky SSR and its footguns, more precise control of the web server configuration, etc.
It's very rare nowadays to see any web devs who don't know the "full stack" from bare Apache/Nginx up to React (or even writing the exact necessary modern plain HTML/CSS/JS). That's why I distinguished the devs who prefer a CMS as "that kind of web dev".
This shift happened in the mid-2010s and I don't know anyone who ever looked back unless they're stuck slow-maintaining something older from before that point in time.
Licensing a CMS now seems like a pointless middleman cost for a subpar product from a time before we had good web standards that were well understood and supported. Every CMS sales pitch seems to be aimed squarely at middle management fearmongering for the most trivial and basic stuff any web dev already knows how to do a lot more efficiently and reliably without a CMS. All devs I see now have experience with these standards using more modern tools at large scale and with the full SDLC and business requirements in mind for over a decade.
> much of the work ends up delegated to the devs anyway
For many implementations though, requiring a dev to make the changes is the failure state.
I love static builds and use them all the time when they're the right fit for the project, but in many cases they are not. I'm also finding that I'm starting to lean towards a CMS more even when it's "just me", but I have a team of agents. i.e. I want the ability to have a voice conversation with a dot / grok bot / etc. and have it update content without it having the ability to do dev type things.
It's the inverted pyramid that has always been sort of Drupal's niche... a small number of all sites, but a large percent of the largest sites in the world.
And fortunately those of us in tech, the amount of software in the world is exploding so all those lanes are getting bigger, even within their niche.
> It's very rare nowadays to see any web devs who don't know the "full stack" from bare Apache/Nginx up to React
citation needed. Pretty much every single React/JS front end dev I've dealt with, doesn't know, understand, or care about the web server aspect itself "Not my problem".
A lot of developers got burned by Drupal in the 2010s. "The drop is always moving" may be gone, but having to do a massive rewrite of a site's template every couple of years and rebuild its plugin ecosystem—even if all one wanted was a secure site—was a lot to manage. Add to it a community that was oriented toward only listening to folks who contributed to the project or made plugins and the bad reputation was earned. I'm not a professional web developer, but I know a few who gave up on Drupal during this time, just as I did. My nonprofit now runs on Wordpress, which isn't perfect, but can handle 1,600 paid members (via a paid plugin) and just works from day to day. My personal site is vastly more sophisticated than it ever was under Drupal since the maintenance is so much less. It's going to take a lot to rebuild this reputation. A lot of love was lost.
yeah, that's the double-edged sword. Drupal can do what it does today because it continually rebuilt it's foundation - but at the same time that sort of movement did cause a lot of pain along the way. At the same time, in the world of "I'll just have my agent rebuild it" makes that sort of change a whole lot easier to deal with - if not the standard everyone may need to adopt.
Drupal earned that reputation for so many architectural upheavals and pointless version churning. I grok innovation, but one of the core properties of web infrastructure is that it's relatively (in a software sense) architecturally stable. Drupal was not that.
It isn't quite as bad as when the codebase was switched to Symfony, but the Drupal project has just kind of abandoned it's core presentation system in favor of the new Canvas tool, and compatibility with the rest of the core seems like an afterthought. So now you have at least 3 competing display configuration solutions, which don't necessarily work together, or entirely work alone.
It's a situation entirely inline with Drupal's reputation: they couldn't just get it right, and now serious Drupal teams don't know which way to go in the ecosystem.
Does anyone need Drupal anymore? You can just Claude Code all kinds of shapes of software.
I don't see how Drupal or anything like it survive. These types of softwares seem fitted to 2006, not 2026.
Using Claude to build things quickly is great - but once you hit a certain level of scale, or have a need for governed workflows & oversight, you're more or less going to want some sort of CMS. When that happens, you can either go it alone, or build on top of a lot of well discussed well thought through solutions to these sorts of problems that the Drupal community has dealt with for a couple of decades.
Claude still has to write software in a target language, often using an established framework, especially one with a lot of examples.
PHP is, in fact, exceptionally good as a language for creating websites.
also the best code is usually less code, and frameworks can be really helpful there.
>You can just Claude Code all kinds of shapes of software.
Drupal is used at large organizations with hundreds of sites, thousands of users, and multiple more-or-less coordinated development teams. It's actually a great target for agentic coding, because it has such a well-established internal API. It can definitely feel like an anachronism, but I think there are few projects that could replace some of it's use cases. It's the B-52 of CMSs.
not a whole lot of documentation, I feel like a lot of knowledge is held within orgs. At my first job I often had to venture into the source code to figure out how something is supposed to work. Copilot has just came out then and it was terrible at helping with a Drupal 10 migration for example because the training data only had 8 and below and a lot of stuff obviously changed in-between.
I reckon AI must be much better now at this since it's doing all sorts of things, but I wonder if you still would need to have the repo cloned so that it can crosscheck with the source code. Since the knowledge cutoff should be around 2025, most of the stuff it knows should be plenty
This is how I view it. If you're going to be hosting dozens or hundreds of sites having a consistent platform like this is important even if Claude Code is doing all of the implementation work. It has understood and workable flows for things like content approval, timed releases, etc. All the things people think about when they talk about "managing content" and for the most part organizations still want human in the loop, especially for gated approvals and auditability.
If I'm thinking of building a single one off site, then yeah I'd probably opt to just let CC handle it without worrying about a framework which is overengineered for my current need. That's what I do with most of the personal projects I work on these days. But I do have a skill to build consistency around the parts that should be consistent for everything I host. Like package shape and types of hooks available for deployment. How sites are publicly exposed and DNS management.
One of the best things about Drupal (years ago, when I used to write plugins and themes), was that you could completely customize the backend, as well as the frontend, and that was a good thing, if you have low-tech users that author content. I despise having to walk people through WordPress' backend.
But that rewriting the base system, every couple of years, was why I dropped it.
Nowadays, with LLMs, it may be time to look at it again...
It still is symfony…
What are the best reasons for a new project to choose Drupal in 2026, apart from familiarity ?
I'm partial to Drupal because I use it a lot - but if you have a large team with a lot of rules around content and making a mistake is a big deal - you don't want to re-invent the wheel with CMS-like functionality.
Remember a while back when the world first heard about Mythos because there was a mismatch between what the "CMS" said was publish, what was shown on the site, and what was "really" available? Those types of problems haven't gone away and if anything are more critical when an army of agents will seek out and find any but of information they can get their hands on.
That is a reason for using something.
Why Drupal rather than another of the many CMS's and frameworks that exist?
Not a best reason, but the reason is often because, in the enterprise, marketing hired dozens of people between 2018 and 2023 from the same handful of Drupal consultancies.
> React has one of the world's largest developer communities. Drupal Canvas code components are written in React, and we designed the developer experience around the tools, patterns, and workflows front-end JavaScript developers already know. They can use their preferred development tools, including modern AI-assisted workflows, without having to learn Drupal-specific concepts or conventions. We've continued to make that experience better, lowering the barrier for a much larger community of developers to build with Drupal.
Ok. As someone who hasn't shipped a Drupal site since halfway through the D8 cycle: is this better or worse than the tumor that is Gutenberg?
pretty sure gutenberg is react based as well
Drupal made me care about abstraction with every feature in any language I worked with. Drupal made me faster by being a little slower. While working with teams where people were doing one off solutions as fast as they could, I never painted myself into a spaghetti code corner.
There isn't a day I don't ask Claude "What would Drupal do?"
I would not be surprised if approaching vibe engineering from the Drupal perspective is the way out of AI slop.
Nonetheless, although I had a blast one evening building custom modules using Claude wishing I had this tool during those hours of stress I suffered 15 years ago, I don't think there is a place for Drupal outside of higher educations marketing.
> I don't think there is a place for Drupal outside of higher educations marketing.
Let's revisit the statement in a year :)
My gut is we're seeing the exact opposite. The scale of publishing + users + need for governance is exploding.
I will say, I liked Drupal more than I expected to the last time I used it. But... it's still Drupal.
It feels dated. Even the "new" designs they're rolling out still feel old. They're working with a dated design system, and honestly, it feels like they had developers build it without bringing actual designers into the process. The result is always functional, but somehow a little awkward. Not unified. There's still like 3-4 different ways to do the same sorts of actions depending on where you are. It's clumsy. It's Drupal!
And true to its roots, Drupal still requires way too many third-party modules to get a build working the way I want. Half of those don't even have the "new" design system applied. So even for a CMS that cares about WCAG, they're still falling short. I'm not sure they'll ever get all the open-source developers on the same page. (I know they have a stated goal of 2027... I don't see it happening.)
More broadly, I don't have much confidence that Drupal modules will be maintained beyond a version or two. That makes anything you build on top of them inherently disposable. Which is fine; a lot of the web is disposable. But it also means I don't want to take ownership of long-term maintenance for projects built on Drupal.
Every time I have to install a third-party module in Drupal, I cringe a little. I know that two or three years down the road, when a new major version comes out, I'll be hunting down the guy who wrote the module, hoping he'll update it. Otherwise, we're forking his repo and taking responsibility for maintaining it and applying security patches ourselves. Cringe.
Meanwhile, I've really enjoyed working with Contentful, Directus, and even Statamic. There are a lot of great CMS options out there these days.
One platform I'd actively warn people away from, though, is Strapi. I've had two false starts with projects where people wanted to use it, only to run into some fundamental flaws.
Like, "Oh, you want to associate one of your 10,000 files with this page? Sure, we'll put them all in a dropdown for you to sift through... and that'll make pages take 2 minutes to load." Cringe. Run. (Ha, wait... and the whole, "We are in France, so we don't answer support emails in August." Literally what their support email told me. Yikes.)
In the last five years, Strapi is the only CMS I've built with that I just couldn't get behind on any level. I would have rather used Drupal for those projects. Ha!
Drupal CMS is working to solve some of this - from better designs to confidence in the choice of modules. Any truly open and free choice is going to have this sort of concern though - but unlike a closed ecosystem, at least you do have a choice or path forward when the situation arises.
Is there an AI-first strategy for CMS design?
yes, but in my opinion it's not a new strategy.
From a site building perspective:
The problems agents bring to the table are the same problems that UGC brought to the table - new scale, untrusted users, an increased need for governance.
From a user experience perspective:
You can't ever really know if it's a human, an agent, a human driving an agent, or an agent driving a human - so stick to information architecture and accessibility best practices.
beyond that though, we're in new territory when it comes to change / scale / security / etc, so if there is a strategy it'll be out of date tomorrow.
It's too late. Drupal 6 turned me off ever using a CMS again. Now I purely use html files in folders with other files in folders. It's great. No maintainence burden, no attack surface, no resource eating always running programs or database that can get corrupted or otherwise in a bad state. And especially no migrating to the new version and everything breaking (especially with non-core stuff).
Is there a compelling reason to even use a CMS at all anymore? I feel like the majority moved on well over a decade ago.
Is it just the last remaining pockets of "that kind" of web dev?
Yes, usually when you have a team and need governance over users / content / state. i.e. a publishing workflow that might have specific regulatory review requirements etc.
We're finding that this is becoming even more critical when users are using agents and the scale of changes / publishing increases. Pair that with things like AI regulations that require records of human providence etc, and a CMS becomes even more important.
In my experience, unless your non-dev CMS contributors are strictly filling in blanks with text (sometimes not even then), much of the work ends up delegated to the devs anyway. They are much better off working on a static build that deploys from CI pipelines in gitlab/github.
The benefits are massive ranging from better versioning, free choice of any tools under the sun, strict access control far away from people who don't even understand text encoding, clean CDN deployments, complete elimination of clunky SSR and its footguns, more precise control of the web server configuration, etc.
It's very rare nowadays to see any web devs who don't know the "full stack" from bare Apache/Nginx up to React (or even writing the exact necessary modern plain HTML/CSS/JS). That's why I distinguished the devs who prefer a CMS as "that kind of web dev".
This shift happened in the mid-2010s and I don't know anyone who ever looked back unless they're stuck slow-maintaining something older from before that point in time.
Licensing a CMS now seems like a pointless middleman cost for a subpar product from a time before we had good web standards that were well understood and supported. Every CMS sales pitch seems to be aimed squarely at middle management fearmongering for the most trivial and basic stuff any web dev already knows how to do a lot more efficiently and reliably without a CMS. All devs I see now have experience with these standards using more modern tools at large scale and with the full SDLC and business requirements in mind for over a decade.
> much of the work ends up delegated to the devs anyway
For many implementations though, requiring a dev to make the changes is the failure state.
I love static builds and use them all the time when they're the right fit for the project, but in many cases they are not. I'm also finding that I'm starting to lean towards a CMS more even when it's "just me", but I have a team of agents. i.e. I want the ability to have a voice conversation with a dot / grok bot / etc. and have it update content without it having the ability to do dev type things.
It's the inverted pyramid that has always been sort of Drupal's niche... a small number of all sites, but a large percent of the largest sites in the world.
And fortunately those of us in tech, the amount of software in the world is exploding so all those lanes are getting bigger, even within their niche.
Thanks for clarifying. I think you're suggesting that there's an "excluded middle" customer that I've just never seen in real life.
> It's very rare nowadays to see any web devs who don't know the "full stack" from bare Apache/Nginx up to React
citation needed. Pretty much every single React/JS front end dev I've dealt with, doesn't know, understand, or care about the web server aspect itself "Not my problem".
> Is it just the last remaining pockets of "that kind" of web dev?
You mean the kind of development that powers nearly the entire web?
Moved on from a cms? No, they’re more used than ever before.
websites are still made out of content, I think?