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.
>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.
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.
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.
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 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 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.
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.
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.
It still is symfony…
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.
>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.
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.
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.
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 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 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.
[delayed]
Moved on from a cms? No, they’re more used than ever before.
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.