Opus 5.5 rewrote an awful, legacy Drupal app from scratch in my preferred stack in four hours. This included handling abandoned plugins, migration to a not-insane database schema, and content fixups from a Drupal 4 backup that fixed truncated cells somewhere in a botched Drupal 6-7-8 upgrade I wasn't part of.
If you want to know everything you need to know about Drupal, have a peek at the community discussion around sitemaps. There are genuine reasons behind the complexity, but a CMS that cannot generate a list of its own URLs, leaving thousands of people baffled, is quite an achievement.
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.
It's genuinely so much better than it's ever been.
I completely understand how people got burnt. The move forward was less about bringing users, site builders, and developers along for the journey and more about providing what enterprise needs.
And one of the enterprises that was front and center was Acquia, Dries' organisation that he set up to offer consultancy services based on Drupal.
Having said all that, it is genuinely a very good product now, and one that LLMs are incredibly good at building with.
The high level of documentation, convention over configuration, and the API-driven nature of Drupal lend themselves very well to LLM assistance.
Considering just how awful WordPress is in terms of security, community, cohesion, code quality and maintainability. I think it's a crying shame that Drupal has lost so much goodwill.
I'm not sure what the solution is, but I'd recommend anyone reading gives it a try with Codex or Claude code, and you'll hopefully see what I mean.
Rural lost almost all of the good will, and foe good reason. It was a dumpster fire with a half arsed ecosystem of extensions. During that period WordPress was flourishing, listening to users, and making sure administration was a lot easier.
Saying that Drupal is better than it has ever been is not much of a statement. It still isnt as easily extensible due to having a smaller community of contributors as an after effect of mismanagement.
I hope they have improved, but their reputation has been earned repeatedly.
It's very extensible. Take a look at CiviCRM, Give, and many other sophisticated extensions, not to mention WooCommerce. Drupal-based businesses facing a complex upgrade often found Wordpress could do everything they needed.
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.
Well I tend to think that "Configuration isn't the most important thing, it's the only thing" and I came to have a lot of respect for how configuration works in modern Drupal after having to work on our Drupal early this year.
> in the world of "I'll just have my agent rebuild it" makes that sort of change a whole lot easier to deal with
Easier in terms of effort and time, but it still costs, and it still adds drag.
The fact that I can do housekeeping much more easily with agents doesn’t make me want to do more of it. The whole point is to free up my time, energy, and thinking for things that are more worthwhile, interesting, and value-adding. That’s my mentality both at home and at work.
If you’re building a framework or a library, whether open source or commercial, and you think agentic and AI native development gives you more license for breaking changes and churn because your users can just fix it up with their agents, then I’m afraid I’ve got some bad news for you because that blade cuts on both sides.
If you can keep churning and breaking stuff, then I can get fed up, drop your shit like a hot rock, and build it myself. And I will.
I’ve just rebuilt my personal site from scratch after getting cheesed off with the framework I used and it didn’t take very long. What’s actually taken longer is making all the improvements I would have liked to make but were too much hassle before, so one needs to relearn shipping discipline, but that’s OK.
Same goes at work. Even major stack changes, like migrating database engine, are so much easier. Yes, you still need to be methodical and disciplined - in fact I’d argue agents make that more important than ever in many enterprise contexts - but it is still so much easier. I’m seeing projects left and right that in the old world would have taken weeks or months executed in days or weeks. It’s wild times.
Because agents can build things, but fortunately for us humans, there's still room for making sure the "right" thing gets built.
i.e. why read a book written by a human when an agent can write one? Why buy a painting that could have been printed.
One of the benefits of open-source and frameworks is they're made up of battle-tested decisions by a lot of people with real skin in the game for a long time. Yes an agent will often solve your problem, and will solve it correctly - as asked, but often a better answer is found by stepping back, evaluating the fundamentals, checking other perspectives, challenging assumptions, and having an opinion.
Having a framework as guardrails (Hah!) for agents is still very powerful, in my experience working with Rails + Claude it works together really well and there's not really a downside compared to doing it completely from scratch.
I'd rather point the agent at and authentication gem and tell it to use that, vs telling it "build authentication, make no mistakes".
I understood the parent comment to mean framework vs. writing everything from scratch, not necessarily about Drupal, Laravel, Symfony. Drupal just came up as it's the thread title. I'd apply that statement to each framework.
The only time I ever allowed myself to have the PHP is a security nightmare conversation at work, I came in the very next morning to find the lone PHP supporter was having to patch the drupal instance he supported because it had been hacked and defaced. I tried not to be smug about it because the timing made it look like maybe I was the culprit, and I was still new there.
But he never mentioned PHP again which was just fine with me.
In trust situations we have a sort of unspoken concept of Original Sin. Essentially once someone has made a security blunder of epic proportions, we can not trust that this is an isolated incident instead of a pervasive one. If The Rot Starts at the Head is true, then how can any amount of rework ever make you trust the thing again?
I looked at the security patch that Drupal applied, and I’m no PHP reader but I was sure I found the same antipattern in two other places in the code that were not patched. I only looked for an hour. There have been years and years of low effort CERT advisories since. From a user standpoint, if you’re not deep into Sunk Cost, this looks like throwing good money after bad. Only rationalization ever makes it seem like a good deal.
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.
They haven't abandoned the core presentation system entirely. I mean, maybe Dries has, but he's not quite the tyrant that Matt is (was?). I agree that it's confusing, and I don't like Canvas, but I also don't use it.
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 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.
That isn't needed anymore. One person can maintain an entirely in-house solution and easily make changes and adaptations.
Have you tried letting AI agents make design decisions on their own? (technical or otherwise), in my experience you still need to properly understand what you want to get good results - you would need to have a deep understanding of all the potential warts, security holes, usability issues etc - developing a CMS via AI is still a substantial project.
>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.
> Drupal is used at large organizations with hundreds of sites, thousands of users, and multiple more-or-less coordinated development teams
Sadly none of this applies to me, so I wonder whether it makes a good argument when my question is "should I use Drupal for my personal hobby website".
I'd say no, at least to start - there's an inherent cost in using a CMS a framework etc. If what you're building is simple enough that a flat file hosted on cloudflare etc, works, then start there.
Once you find you do have a need for something more complex (i.e. you have a team, want to give agents governed access etc), then it's pretty easy to go from a flat file to something more complex.
One of the appeals of LLM-generated code, to me, is that you can often write things without a framework and reduce the total amount of code in the system, which tends to make it much more understandable overall.
LLMs are infamous for generating unnecessarily complex and inefficient code. And it was always possible to write things without a framework, people just refused to do so.
In my experience LLMs are mostly very keen to write a function themselves instead of reach for a library. The code itself tends to be pretty straightforward and if anything is characterised by a lack of extra abstractions. What that usually means is that you have more code that the LLM has written and less code that you are depending on in libraries. If you are concerned about understanding the system as a whole this is less total to deal with. Previously, you could also write this way (i.e. without a framework and with relatively few libraries), but it would be a lot slower.
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...
>But that rewriting the base system, every couple of years
To be fair, they did it once, from v7 to v8. But yeah, a major release does break APIs. I'm concerned with how Drupal Canvas is bolted on, but it looks like it's basically a content editor UI that is separate from the site admin UI, which is a good idea.
As someone who has recently started Pair Programming with LLMs—something I never managed to bring about with a human, sadly—I'd like to say: Sure you can do it. Sure, team up with a bunch of friends, a forest next door and build your dream cabin. Then compare that to a prefab from the Sears Modern Homes line. It's still 30'000 parts, 25 tons, est. 90 days build time, but it will be vastly easier, especially if one of your pals happens to be great at digging up and bringing together assembly instructions, general technical infos and past experiences from other builders for all the many snags you'll still hit when erecting that thing.
Can't answer the specifically "Drupal" part (as for me I once had a certain pressure behind me to use it, found it atrocious at the time and won't look to repeat that; if their software is much better / much more to my taste now, good on them). But in principle, at least from a certain app size upwards, I'd rather start with something working in principle, then improve on it.
That said, it might still be more difficult to get things right with Drupal than with some other softwares where you have better continuity between versions. At least traditional search engine results tend to handle version changes rather poorly meaning you'll get tons of advice that don't really apply anymore because they're years old. That happened a lot to me when trying to help out a friend with a WordPress installation.
Broadly, I always felt that "Drupal and the others" vs. Wordpress was a perfect example of "evolution over intelligent design."
This probably changed somewhere down the line, but I genuinely believe the most significant factor in Wordpress becoming the dominant CMS is that, in the beginning, for a long time, it wasn't trying to be a CMS, just a blog engine.
I came into Drupal right as 8 was becoming the standard, and facilitated a number of Drupal 7 migrations, so I don't have the experience of getting burned by churn, but I will say that coming from WordPress, Drupal was a huge breath of fresh air. Better code, better community, better architecture etc.
The Drupal core team is moving really fast to improve its reputation, and I think a lot of the changes are good. The AI integration is pretty solid, and the Symfony framework is solid and easy to build on. I think the move to Canvas is misguided and from inside the community I can tell you that not everyone is on board, but it is nice that both paths are possible.
As many here have said: If you have large teams that manage large amounts of content, Drupal is really the only option. If you're making one-off sites or "brochure sites," then vibe-coding them is just as good as anything, but I don't think that's ever been Drupal's core concern.
Agreed. Brochure sites... use whatever. But once you begin to pile on the requirements: automatic image manipulation (resizing, scaling, focal point), complex user roles and permissions, rules-based content editing workflows, multiple search indexes, semantic search, complex media management, internal AI site agent, API and MCP servers, GIS and mapping features, file management (public, private, and cloud hosted), custom entities and fields that seamlessly work with the rest of the system, etc., you end up either using Drupal or bolting on your Drupal-like features to another CMS. I like to think of Drupal as the worst CMS, except for all the others.
Drupal is now a very different animal than it was in the Drupal 7 heyday. It's confusing for folks used to WordPress and similar as you're not gonna be uploading it to a regular old shared hosting provider. There's no way you're using modern Drupal without SSH access and using command line to install and update. And thoroughly learning how the Drupal bits all work together.
Drupal CMS is what a lot of people suggest for new folks, but it isn't explained what it is on the Drupal website. It's apparently a set of pre-configured extensions, templates, AI, and settings. Drupal has a version on their site to download but it says it's a "trial" and requires registration to get it, further increasing friction: https://new.drupal.org/drupal-cms/trial#:~:text=start%20your...
Once you do get it, it may or may not work. When I last tried the Windows version, it didn't work and just gave the old Drupal white screen of death in the browser.
When I've seen discussions in the Drupal sub-reddit, most of the recommendations on how to do something seem to be some version of 'have Claude do it for you'. And the Drupal homepage is very AI forward and mentions AI 9 times.
Drupal's largest install base was back in the Drupal 7 days, which was the last major version that supported upgrading in place from the previous versions. Major compatibility changes started with 8 and continued. About 1/2 the sites that used to run Drupal 7 migrated to WordPress rather than upgrade. Today, there are about the same number of sites running Drupal 7 as the current Drupal 11, which speaks volumes.
As someone that still uses a paid, extended-support version of Drupal 7 and is likely switching my big legacy site to Backdrop CMS (actively maintained Drupal 7 fork) and my other two sites to another CMS, it doesn't seem like there's a place for folks like me in the current world of Drupal.
> which was the last major version that supported upgrading in place from the previous versions
This isn't correct. Yes it was true from Drupal 7 to 8, but one of the primary goals of that change was so that every major version after could have seamless in-place upgrades - which they have. Yes there's deprecated code etc. that you might run into in contrib. or custom modules, but the site upgrades themselves are easier than ever.
I'm aware that the modern Drupal supports in-place upgrades for the most part, though white screen of death reports are still pretty common. My point was that there was a split from classic Drupal to modern 'you have to use the command line and should know how to code' Drupal in terms of upgrades from the 7 to 8 split-off.
From all my reading in the Drupal subreddit, modern Drupal isn't especially useful for real world scenarios without a bunch of contributed modules and stuff... hence Drupal CMS. Additionally, folks were recommending not using Drupal 11 until it had been out for well more than a year due to the sad state of contributed module upgrades. I'd wager this is due to the much smaller Drupal community than the version 7 highs.
> modern 'you have to use the command line and should know how to code' Drupal
I get needing to have command line skills for a web framework upgrade (doesn't seem like an unreasonable expectation to me), but why on earth would an upgrade require writing your own code?
Drupal is a name I haven't heard in a long time, so the reputation that they're light-years ahead of is probably a low bar for me. I just recall every time I tried to adopt it or learn my way around it, the curve was high, not even compared to anything, it was just a lot. I'd love to give it another chance, but there are so many good options and such different ways of doing web dev these days, I'm not sure what benefit this would have.
Also, what an amazing day to pick to talk about anything PHP.
Drupal has been pretty good ever since Drupal 8. A lot better than WordPress IME, which isn't exactly a high bar, but it's THE bar now.
The churn stopped after D8 - upgrades from D8 -> D9 -> D10 have all been painless with no major overhauls to the API. The template system, the granular caching infrastructure, namespacing, package management, Symfony core, are good.
It's a solid framework to build on without having to reinvent the CMS wheel.
I heard it expressed that AI is bringing a new era of small and personal software.
I think CMSes and websites are where that is most applicable. You no longer need these generalized abstractions and can now make your interfaces and data types just perfectly match your use case with little effort.
We went through great pains to build these mammoth, one-size fits all applications like Drupal and Wordpress for running dynamic sites across industries and companies with very little in common.
These days, I love to stay close to the model and stay close to the metal.
Glad to see we can keep the "every developer eventually builds a CMS" joke running for another two decades. I still think it's a bad idea to build your own, and I wouldn't put Drupal or Wordpress near the top of the pile for good ones anyway, but I'd still put them above any bespoke CMS I've ever seen.
Well, to a CMS developer, a lot of problems look like CMS problems. I know because I used to be paid to think like that. Portfolio website? CMS. Support ticket database? CMS. Newspaper layout system, intranet portal, blog, restaurant menu, identity verification system, etc? Yeah, we built all of it using a CMS. It made a lot of sense at the time because HTML and CSS were young and difficult to wrangle. Today, most of the reasons to build or use a CMS have evaporated.
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.
That seems more like an implementation opinion vs. a core property.
Agree that it was a pain to keep up with sometimes, but if software doesn't evolve over a 25 year timespan - it's likely going to be stuck in the past.
The reason Drupal can do what it does today is because of this willingness to rebuild - otherwise it'd just be a CMS that solves problems from the early 2000s.
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.
I'd recommend Drupal specifically when you have the need for strong governed management of users + content + workflow and you want something that is battle tested without having to make all the decisions that get you there.
This one goes back 19+ years and has to do with 404s when a visitor looks for favicon but doesn't fully follow the standard of where that file could be. It happened with ie6 back then, and happens with some agents and services today. The easy fix is to put a favicon in the root, but that's a bandaid that runs into a bunch of edge case issues when creating a platform or doing something non-standard. Suppressing the error message is another option, but there's a performance and delivery cost into how that's done. If you ask a frontier model today how to fix this on your site, you'll likely get the easy "simple" answer.
Long way of saying, Drupal is an accumulation of battle tested decisions from a bunch of smart people over a long period of time - and if your need matches the usual intent of Drupal - users + content + delivery + rules around that - then that's a strong reason to explore it for your use case.
Depends on your project. Do you have a large content team managing a large amount of content? That's Drupal's strength and I don't think there's anything better for it.
Other than that, familiarity is really the best selling point.
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.
I switched to ProcessWire [1] a couple of years ago, and haven't been happier.
It succeeded to do what Drupal tried but never managed to do:
It is both extremely stable and extremely flexible at the same time.
By having an extremely generic and small core, combined with an extremely powerful programmatic API (basically jquery for data from the CMS, but better), you don't need fiftyeleven modules to achieve some basic tasks.
We can do better than PHP, EAV-style db schemas, year 2000ish CMSes and, thus, Drupal.
It' reputation is earned.
A fresh web stack with a traditional (non-EAV) db schema and proper programming layers is a much better DX, I'd say. All very doable with LLM-assisted coding.
This might be one of the funniest articles ever. "Drupal is now light-years ahed of its reputation", yet it's vulnerable to one of the most serious and easily-exploitable RCEs in the history of computing.
It's time to abandon PHP and C-based software (i.e. PHP). The clock's ticking.
I don't use any of those for anything running dynamically on the web or accepting untrusted user data. Unless it is a quick student project, there's rarely a reason to do that anymore. It's also not the same thing, both NodeJS and Python with ASGI handle less parts of web requests than PHP is meant to.
Meanwhile, there are different threat models to any type of web application, it's just that PHP has repeatedly failed us in any threat model, same as C in most threat models that don't involve compiling it to WASM or running it air-gapped.
Leaving memory unsafe runtimes and interpreters directly available to public web traffic is a liability I don't want for me and users don't deserve to face the consequences of it whenever they are trusting you with their data. Rust and Golang even with all of their design issues should be the baseline for internet facing software nowadays.
As for the Linux kernel, everything I run on it is inside a VM (or a microVM) instead of relying on containers exclusively, because I can't trust a C kernel to not have vulnerabilities.
Most microVMs run on extremely stripped down versions of Linux or NetBSD. Not the same thing as relying on PAM, SystemD, namespaces and cgroups to protect your application
Funnily enough, regarding SoftTalker's point, just a few hours after my original comment, CVE-2026-110264 (a CVSS 10.0... worse than PHP's RCE) rolled in for GitLab, which would be prevented by using a memory safe language to write the interpreter instead of C.
What do writers like to use these days? I remember everyone hated Drupal or anything other than Wordpress, to a point that we had Wordpress as the tool all the writers used, and we just used WP-database to serve on a completely different system.
Seven or eight years ago, I led a project for a large media company to consolidate publishing workflows across multiple products, moving everything from several content management systems to Drupal.
After evaluating the landscape, my take was that the project was a waste of time and wouldn’t benefit the company. But a large consultancy was involved, so we had to pick a CMS. We picked Drupal. The result was exactly what management wanted: a single CMS, well-defined taxonomies, and all the content in one place.
Unsurprisingly, the writers hated it. They’d been forced to give up specialized tools for something half-baked that mostly did the same things.
The development experience was atrocious. Scaling was difficult, rolling upgrades and deployments without downtime were nearly impossible, and we constantly ran into bugs and limitations in the existing plugins. We had to bring in Drupal consultants at $300 an hour to get the project over the finish line, but we eventually did. All we ended up using was the admin interface and a GraphQL API, which the company’s products then had to be rebuilt around.
Management wanted everything hosted by Acquia, so we ended up paying $100,000 a year for a few servers that would have cost, at worst, a few hundred bucks a year on Hetzner.
By the original requirements, the project was a success. We managed to move all the traffic over without any downtime. Shortly afterward, I left the company because of how miserable the project had made me.
A few days ago, out of curiosity, I checked whether they were still using Drupal. It turns out management hadn’t learned from its past mistakes: they’d migrated to yet another CMS, even though it was obvious non-management the problem was the business model not the CMS. What of waste of time and money.
> 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?
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.
We've been hearing this for years. On the Drupal site, it says it's a trial and makes you register to download it. Last time I downloaded the Windows package, it gave a Drupal white screen of death. I'm not planning on registering again to try it again. Nor do I want to use AI to install and manage my CMS.
That trial form is if you want a desktop installer from the Drupal Association. You can still install Drupal CMS directly with no form by clicking the "Download the Composer package instead" button next to that.
I don't have a strong opinion on Drupal (last used it 15? years ago, it was fine) but the people who make don't get to say "Drupal is now light-years ahead of its reputation.". That's what everyone says of their own stuff, just no.
Why wouldn't the makers of something be able to state their opinion on it? Especially an open, collaborative project with many people, and opinions, behind it.
If you disagree with the sentiment, it'd be interesting to here why - that's the sort of information that's extremely useful for makers.
You would probably never see anyone in a (community) leadership role say "we're worse than our reputation", the most humble you'd get is "we match our reputation" (if it's good, not bad) but "we're better than everyone says" just feels wrong to me.
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.
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).
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.
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".
Unless we're talking about figma-like web apps, Content is usually a different department than development.
I know it's becoming more and more outdated nowadays, but if a magazine or a news website is still written by humans rather than AI they need a way to provide formatted text and media, and preview the output.
On the other hand I should add that i've also seen an upward growth in CMSes like WordPress being used exclusively as Online Editors, with content ultimately being exported trough REST to completely different backends and frontends, like a Firebase/NextJS infra.
I'd argue that content written by non-humans makes this even more important. You still likely have a need for a publishing / review workflow & attribution and a way to ensure standards are enforced and not just left to the end-user's own judgement.
Separating delivery from content management also reinforces this. Set up a governed content / user workflow and then let an agent focus on just the presentation after pulling in the content. I'd say this extends well beyond rest as well. A user interacting with something like a voice assistant in an agent might actually be using many interfaces at once (mcp from the assistant, HTML in a card, WebMCP alongside the HTML, browser open on another device for the human.) When that happens you want one canoninical system for the content.
Opus 5.5 rewrote an awful, legacy Drupal app from scratch in my preferred stack in four hours. This included handling abandoned plugins, migration to a not-insane database schema, and content fixups from a Drupal 4 backup that fixed truncated cells somewhere in a botched Drupal 6-7-8 upgrade I wasn't part of.
If you want to know everything you need to know about Drupal, have a peek at the community discussion around sitemaps. There are genuine reasons behind the complexity, but a CMS that cannot generate a list of its own URLs, leaving thousands of people baffled, is quite an achievement.
What was your preferred stack?
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.
I maintained websites built in Drupal, WordPress, etc for medium sized businesses back in 2010s.
Drupal has been absolute mess for maintenance, backwards compatibility, responsive ness (code/dev wise).
People started flocking more to WP and Drupal docs weren't just up to date as people were moving away.
Nothing will change my mine over Drupal at this point still especiallyin this day and age. Better create one yourself or mod WP.
---
Whatever the post says about it's "light-years ahead" sounds like a tiktok influencer talk.
It's genuinely so much better than it's ever been.
I completely understand how people got burnt. The move forward was less about bringing users, site builders, and developers along for the journey and more about providing what enterprise needs.
And one of the enterprises that was front and center was Acquia, Dries' organisation that he set up to offer consultancy services based on Drupal.
Having said all that, it is genuinely a very good product now, and one that LLMs are incredibly good at building with.
The high level of documentation, convention over configuration, and the API-driven nature of Drupal lend themselves very well to LLM assistance.
Considering just how awful WordPress is in terms of security, community, cohesion, code quality and maintainability. I think it's a crying shame that Drupal has lost so much goodwill.
I'm not sure what the solution is, but I'd recommend anyone reading gives it a try with Codex or Claude code, and you'll hopefully see what I mean.
Now at this point, it's not the usability or how good it is over other products or how you can do more with AIs.
Drupal needs to market how well it can people make $ or at least save. ROI is a good KPI to bring up, if the team has data to back it up, etc.
Rural lost almost all of the good will, and foe good reason. It was a dumpster fire with a half arsed ecosystem of extensions. During that period WordPress was flourishing, listening to users, and making sure administration was a lot easier.
Saying that Drupal is better than it has ever been is not much of a statement. It still isnt as easily extensible due to having a smaller community of contributors as an after effect of mismanagement.
I hope they have improved, but their reputation has been earned repeatedly.
WordPress has never been much more than a blogging engine unfortunately.
It's very extensible. Take a look at CiviCRM, Give, and many other sophisticated extensions, not to mention WooCommerce. Drupal-based businesses facing a complex upgrade often found Wordpress could do everything they needed.
Well, dri.es is the drupal creator :D
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.
Well I tend to think that "Configuration isn't the most important thing, it's the only thing" and I came to have a lot of respect for how configuration works in modern Drupal after having to work on our Drupal early this year.
> in the world of "I'll just have my agent rebuild it" makes that sort of change a whole lot easier to deal with
Easier in terms of effort and time, but it still costs, and it still adds drag.
The fact that I can do housekeeping much more easily with agents doesn’t make me want to do more of it. The whole point is to free up my time, energy, and thinking for things that are more worthwhile, interesting, and value-adding. That’s my mentality both at home and at work.
If you’re building a framework or a library, whether open source or commercial, and you think agentic and AI native development gives you more license for breaking changes and churn because your users can just fix it up with their agents, then I’m afraid I’ve got some bad news for you because that blade cuts on both sides.
If you can keep churning and breaking stuff, then I can get fed up, drop your shit like a hot rock, and build it myself. And I will.
I’ve just rebuilt my personal site from scratch after getting cheesed off with the framework I used and it didn’t take very long. What’s actually taken longer is making all the improvements I would have liked to make but were too much hassle before, so one needs to relearn shipping discipline, but that’s OK.
Same goes at work. Even major stack changes, like migrating database engine, are so much easier. Yes, you still need to be methodical and disciplined - in fact I’d argue agents make that more important than ever in many enterprise contexts - but it is still so much easier. I’m seeing projects left and right that in the old world would have taken weeks or months executed in days or weeks. It’s wild times.
Why use Drupal at all if the agent can just build things?
Because agents can build things, but fortunately for us humans, there's still room for making sure the "right" thing gets built.
i.e. why read a book written by a human when an agent can write one? Why buy a painting that could have been printed.
One of the benefits of open-source and frameworks is they're made up of battle-tested decisions by a lot of people with real skin in the game for a long time. Yes an agent will often solve your problem, and will solve it correctly - as asked, but often a better answer is found by stepping back, evaluating the fundamentals, checking other perspectives, challenging assumptions, and having an opinion.
Having a framework as guardrails (Hah!) for agents is still very powerful, in my experience working with Rails + Claude it works together really well and there's not really a downside compared to doing it completely from scratch.
I'd rather point the agent at and authentication gem and tell it to use that, vs telling it "build authentication, make no mistakes".
Isn't that an argument for pointing an agent at symfony or laravel, not at drupal?
I understood the parent comment to mean framework vs. writing everything from scratch, not necessarily about Drupal, Laravel, Symfony. Drupal just came up as it's the thread title. I'd apply that statement to each framework.
The only time I ever allowed myself to have the PHP is a security nightmare conversation at work, I came in the very next morning to find the lone PHP supporter was having to patch the drupal instance he supported because it had been hacked and defaced. I tried not to be smug about it because the timing made it look like maybe I was the culprit, and I was still new there.
But he never mentioned PHP again which was just fine with me.
In trust situations we have a sort of unspoken concept of Original Sin. Essentially once someone has made a security blunder of epic proportions, we can not trust that this is an isolated incident instead of a pervasive one. If The Rot Starts at the Head is true, then how can any amount of rework ever make you trust the thing again?
I looked at the security patch that Drupal applied, and I’m no PHP reader but I was sure I found the same antipattern in two other places in the code that were not patched. I only looked for an hour. There have been years and years of low effort CERT advisories since. From a user standpoint, if you’re not deep into Sunk Cost, this looks like throwing good money after bad. Only rationalization ever makes it seem like a good deal.
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.
They haven't abandoned the core presentation system entirely. I mean, maybe Dries has, but he's not quite the tyrant that Matt is (was?). I agree that it's confusing, and I don't like Canvas, but I also don't use it.
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.
> 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.
That isn't needed anymore. One person can maintain an entirely in-house solution and easily make changes and adaptations.
Not nearly enough time has passed to make any conclusions about long-term maintainability of LLM-written code.
Have you tried letting AI agents make design decisions on their own? (technical or otherwise), in my experience you still need to properly understand what you want to get good results - you would need to have a deep understanding of all the potential warts, security holes, usability issues etc - developing a CMS via AI is still a substantial project.
>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.
> Drupal is used at large organizations with hundreds of sites, thousands of users, and multiple more-or-less coordinated development teams
Sadly none of this applies to me, so I wonder whether it makes a good argument when my question is "should I use Drupal for my personal hobby website".
I'd say no, at least to start - there's an inherent cost in using a CMS a framework etc. If what you're building is simple enough that a flat file hosted on cloudflare etc, works, then start there.
Once you find you do have a need for something more complex (i.e. you have a team, want to give agents governed access etc), then it's pretty easy to go from a flat file to something more complex.
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.
A web accessible PHP runtime is, in fact, a giant security vulnerability and always had been.
also the best code is usually less code, and frameworks can be really helpful there.
One of the appeals of LLM-generated code, to me, is that you can often write things without a framework and reduce the total amount of code in the system, which tends to make it much more understandable overall.
LLMs are infamous for generating unnecessarily complex and inefficient code. And it was always possible to write things without a framework, people just refused to do so.
In my experience LLMs are mostly very keen to write a function themselves instead of reach for a library. The code itself tends to be pretty straightforward and if anything is characterised by a lack of extra abstractions. What that usually means is that you have more code that the LLM has written and less code that you are depending on in libraries. If you are concerned about understanding the system as a whole this is less total to deal with. Previously, you could also write this way (i.e. without a framework and with relatively few libraries), but it would be a lot slower.
Frankly everything is now. Anyone can use Rust or Go for this now.
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...
>But that rewriting the base system, every couple of years
To be fair, they did it once, from v7 to v8. But yeah, a major release does break APIs. I'm concerned with how Drupal Canvas is bolted on, but it looks like it's basically a content editor UI that is separate from the site admin UI, which is a good idea.
I think from v5 to v6, as well. v6 was the last one I worked with (been awhile).
Also, there were a whole plethora of extensions (not just "plugins"). Some of those broke, while others, did not.
As someone who has recently started Pair Programming with LLMs—something I never managed to bring about with a human, sadly—I'd like to say: Sure you can do it. Sure, team up with a bunch of friends, a forest next door and build your dream cabin. Then compare that to a prefab from the Sears Modern Homes line. It's still 30'000 parts, 25 tons, est. 90 days build time, but it will be vastly easier, especially if one of your pals happens to be great at digging up and bringing together assembly instructions, general technical infos and past experiences from other builders for all the many snags you'll still hit when erecting that thing.
Can't answer the specifically "Drupal" part (as for me I once had a certain pressure behind me to use it, found it atrocious at the time and won't look to repeat that; if their software is much better / much more to my taste now, good on them). But in principle, at least from a certain app size upwards, I'd rather start with something working in principle, then improve on it.
That said, it might still be more difficult to get things right with Drupal than with some other softwares where you have better continuity between versions. At least traditional search engine results tend to handle version changes rather poorly meaning you'll get tons of advice that don't really apply anymore because they're years old. That happened a lot to me when trying to help out a friend with a WordPress installation.
It still is symfony…
Broadly, I always felt that "Drupal and the others" vs. Wordpress was a perfect example of "evolution over intelligent design."
This probably changed somewhere down the line, but I genuinely believe the most significant factor in Wordpress becoming the dominant CMS is that, in the beginning, for a long time, it wasn't trying to be a CMS, just a blog engine.
I came into Drupal right as 8 was becoming the standard, and facilitated a number of Drupal 7 migrations, so I don't have the experience of getting burned by churn, but I will say that coming from WordPress, Drupal was a huge breath of fresh air. Better code, better community, better architecture etc.
The Drupal core team is moving really fast to improve its reputation, and I think a lot of the changes are good. The AI integration is pretty solid, and the Symfony framework is solid and easy to build on. I think the move to Canvas is misguided and from inside the community I can tell you that not everyone is on board, but it is nice that both paths are possible.
As many here have said: If you have large teams that manage large amounts of content, Drupal is really the only option. If you're making one-off sites or "brochure sites," then vibe-coding them is just as good as anything, but I don't think that's ever been Drupal's core concern.
Agreed. Brochure sites... use whatever. But once you begin to pile on the requirements: automatic image manipulation (resizing, scaling, focal point), complex user roles and permissions, rules-based content editing workflows, multiple search indexes, semantic search, complex media management, internal AI site agent, API and MCP servers, GIS and mapping features, file management (public, private, and cloud hosted), custom entities and fields that seamlessly work with the rest of the system, etc., you end up either using Drupal or bolting on your Drupal-like features to another CMS. I like to think of Drupal as the worst CMS, except for all the others.
Drupal is now a very different animal than it was in the Drupal 7 heyday. It's confusing for folks used to WordPress and similar as you're not gonna be uploading it to a regular old shared hosting provider. There's no way you're using modern Drupal without SSH access and using command line to install and update. And thoroughly learning how the Drupal bits all work together.
Drupal CMS is what a lot of people suggest for new folks, but it isn't explained what it is on the Drupal website. It's apparently a set of pre-configured extensions, templates, AI, and settings. Drupal has a version on their site to download but it says it's a "trial" and requires registration to get it, further increasing friction: https://new.drupal.org/drupal-cms/trial#:~:text=start%20your...
Once you do get it, it may or may not work. When I last tried the Windows version, it didn't work and just gave the old Drupal white screen of death in the browser.
When I've seen discussions in the Drupal sub-reddit, most of the recommendations on how to do something seem to be some version of 'have Claude do it for you'. And the Drupal homepage is very AI forward and mentions AI 9 times.
Drupal's largest install base was back in the Drupal 7 days, which was the last major version that supported upgrading in place from the previous versions. Major compatibility changes started with 8 and continued. About 1/2 the sites that used to run Drupal 7 migrated to WordPress rather than upgrade. Today, there are about the same number of sites running Drupal 7 as the current Drupal 11, which speaks volumes.
As someone that still uses a paid, extended-support version of Drupal 7 and is likely switching my big legacy site to Backdrop CMS (actively maintained Drupal 7 fork) and my other two sites to another CMS, it doesn't seem like there's a place for folks like me in the current world of Drupal.
> which was the last major version that supported upgrading in place from the previous versions
This isn't correct. Yes it was true from Drupal 7 to 8, but one of the primary goals of that change was so that every major version after could have seamless in-place upgrades - which they have. Yes there's deprecated code etc. that you might run into in contrib. or custom modules, but the site upgrades themselves are easier than ever.
I'm aware that the modern Drupal supports in-place upgrades for the most part, though white screen of death reports are still pretty common. My point was that there was a split from classic Drupal to modern 'you have to use the command line and should know how to code' Drupal in terms of upgrades from the 7 to 8 split-off.
From all my reading in the Drupal subreddit, modern Drupal isn't especially useful for real world scenarios without a bunch of contributed modules and stuff... hence Drupal CMS. Additionally, folks were recommending not using Drupal 11 until it had been out for well more than a year due to the sad state of contributed module upgrades. I'd wager this is due to the much smaller Drupal community than the version 7 highs.
> modern 'you have to use the command line and should know how to code' Drupal
I get needing to have command line skills for a web framework upgrade (doesn't seem like an unreasonable expectation to me), but why on earth would an upgrade require writing your own code?
Drupal is a name I haven't heard in a long time, so the reputation that they're light-years ahead of is probably a low bar for me. I just recall every time I tried to adopt it or learn my way around it, the curve was high, not even compared to anything, it was just a lot. I'd love to give it another chance, but there are so many good options and such different ways of doing web dev these days, I'm not sure what benefit this would have.
Also, what an amazing day to pick to talk about anything PHP.
Drupal has been pretty good ever since Drupal 8. A lot better than WordPress IME, which isn't exactly a high bar, but it's THE bar now.
The churn stopped after D8 - upgrades from D8 -> D9 -> D10 have all been painless with no major overhauls to the API. The template system, the granular caching infrastructure, namespacing, package management, Symfony core, are good.
It's a solid framework to build on without having to reinvent the CMS wheel.
My gosh, Drupal, what a blast from the past! That, and Joomla. Haven't thought about those in years. Glad to see they're still going.
I heard it expressed that AI is bringing a new era of small and personal software.
I think CMSes and websites are where that is most applicable. You no longer need these generalized abstractions and can now make your interfaces and data types just perfectly match your use case with little effort.
We went through great pains to build these mammoth, one-size fits all applications like Drupal and Wordpress for running dynamic sites across industries and companies with very little in common.
These days, I love to stay close to the model and stay close to the metal.
Glad to see we can keep the "every developer eventually builds a CMS" joke running for another two decades. I still think it's a bad idea to build your own, and I wouldn't put Drupal or Wordpress near the top of the pile for good ones anyway, but I'd still put them above any bespoke CMS I've ever seen.
Well, to a CMS developer, a lot of problems look like CMS problems. I know because I used to be paid to think like that. Portfolio website? CMS. Support ticket database? CMS. Newspaper layout system, intranet portal, blog, restaurant menu, identity verification system, etc? Yeah, we built all of it using a CMS. It made a lot of sense at the time because HTML and CSS were young and difficult to wrangle. Today, most of the reasons to build or use a CMS have evaporated.
What I mean is CMS isn’t required now for most web projects.
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.
> core properties of web infrastructure
That seems more like an implementation opinion vs. a core property.
Agree that it was a pain to keep up with sometimes, but if software doesn't evolve over a 25 year timespan - it's likely going to be stuck in the past.
The reason Drupal can do what it does today is because of this willingness to rebuild - otherwise it'd just be a CMS that solves problems from the early 2000s.
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?
Fair point.
I'd recommend Drupal specifically when you have the need for strong governed management of users + content + workflow and you want something that is battle tested without having to make all the decisions that get you there.
There's an old issue in the Drupal queues that I really like that exemplifies this: https://www.drupal.org/project/drupal/issues/174940
This one goes back 19+ years and has to do with 404s when a visitor looks for favicon but doesn't fully follow the standard of where that file could be. It happened with ie6 back then, and happens with some agents and services today. The easy fix is to put a favicon in the root, but that's a bandaid that runs into a bunch of edge case issues when creating a platform or doing something non-standard. Suppressing the error message is another option, but there's a performance and delivery cost into how that's done. If you ask a frontier model today how to fix this on your site, you'll likely get the easy "simple" answer.
Long way of saying, Drupal is an accumulation of battle tested decisions from a bunch of smart people over a long period of time - and if your need matches the usual intent of Drupal - users + content + delivery + rules around that - then that's a strong reason to explore it for your use case.
Depends on your project. Do you have a large content team managing a large amount of content? That's Drupal's strength and I don't think there's anything better for it.
Other than that, familiarity is really the best selling point.
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.
The best reasons are Drupal's features and functionality match the requirements of your project the best.
Until you define the project, you can't talk about what stack to use.
Same reason as some people like to get their balls slapped.
I switched to ProcessWire [1] a couple of years ago, and haven't been happier.
It succeeded to do what Drupal tried but never managed to do:
It is both extremely stable and extremely flexible at the same time.
By having an extremely generic and small core, combined with an extremely powerful programmatic API (basically jquery for data from the CMS, but better), you don't need fiftyeleven modules to achieve some basic tasks.
[1] https://processwire.com (don't get put off by the .com. It is open source).
We can do better than PHP, EAV-style db schemas, year 2000ish CMSes and, thus, Drupal.
It' reputation is earned.
A fresh web stack with a traditional (non-EAV) db schema and proper programming layers is a much better DX, I'd say. All very doable with LLM-assisted coding.
I have a vision of a CMS for a SSG.
Maybe soon I can set my agents on it
The very most you can say for Drupal is that it is better than Wordpress at its worst. All the goodwill for Drupal was burnt years ago.
This might be one of the funniest articles ever. "Drupal is now light-years ahed of its reputation", yet it's vulnerable to one of the most serious and easily-exploitable RCEs in the history of computing.
It's time to abandon PHP and C-based software (i.e. PHP). The clock's ticking.
Give up on python, perl, ruby, lua, shell scripting, etc. also then. Probably linux itself. It's all built on C.
I don't use any of those for anything running dynamically on the web or accepting untrusted user data. Unless it is a quick student project, there's rarely a reason to do that anymore. It's also not the same thing, both NodeJS and Python with ASGI handle less parts of web requests than PHP is meant to.
Meanwhile, there are different threat models to any type of web application, it's just that PHP has repeatedly failed us in any threat model, same as C in most threat models that don't involve compiling it to WASM or running it air-gapped.
Leaving memory unsafe runtimes and interpreters directly available to public web traffic is a liability I don't want for me and users don't deserve to face the consequences of it whenever they are trusting you with their data. Rust and Golang even with all of their design issues should be the baseline for internet facing software nowadays.
As for the Linux kernel, everything I run on it is inside a VM (or a microVM) instead of relying on containers exclusively, because I can't trust a C kernel to not have vulnerabilities.
Huh what :) And that VM/microVM is running on top of...Windows? :)
Most microVMs run on extremely stripped down versions of Linux or NetBSD. Not the same thing as relying on PAM, SystemD, namespaces and cgroups to protect your application
Funnily enough, regarding SoftTalker's point, just a few hours after my original comment, CVE-2026-110264 (a CVSS 10.0... worse than PHP's RCE) rolled in for GitLab, which would be prevented by using a memory safe language to write the interpreter instead of C.
What do writers like to use these days? I remember everyone hated Drupal or anything other than Wordpress, to a point that we had Wordpress as the tool all the writers used, and we just used WP-database to serve on a completely different system.
It seems everyone has gone to Substack and Medium now because those are the only things people actually read. :(
Seven or eight years ago, I led a project for a large media company to consolidate publishing workflows across multiple products, moving everything from several content management systems to Drupal.
After evaluating the landscape, my take was that the project was a waste of time and wouldn’t benefit the company. But a large consultancy was involved, so we had to pick a CMS. We picked Drupal. The result was exactly what management wanted: a single CMS, well-defined taxonomies, and all the content in one place.
Unsurprisingly, the writers hated it. They’d been forced to give up specialized tools for something half-baked that mostly did the same things.
The development experience was atrocious. Scaling was difficult, rolling upgrades and deployments without downtime were nearly impossible, and we constantly ran into bugs and limitations in the existing plugins. We had to bring in Drupal consultants at $300 an hour to get the project over the finish line, but we eventually did. All we ended up using was the admin interface and a GraphQL API, which the company’s products then had to be rebuilt around.
Management wanted everything hosted by Acquia, so we ended up paying $100,000 a year for a few servers that would have cost, at worst, a few hundred bucks a year on Hetzner.
By the original requirements, the project was a success. We managed to move all the traffic over without any downtime. Shortly afterward, I left the company because of how miserable the project had made me.
A few days ago, out of curiosity, I checked whether they were still using Drupal. It turns out management hadn’t learned from its past mistakes: they’d migrated to yet another CMS, even though it was obvious non-management the problem was the business model not the CMS. What of waste of time and money.
> 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?
I don't like Canvas, and I don't use it, but I don't feel like it's being pushed on developers in the same way that Gutenberg was.
pretty sure gutenberg is react based as well
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.
> Drupal CMS is working to solve some of this
We've been hearing this for years. On the Drupal site, it says it's a trial and makes you register to download it. Last time I downloaded the Windows package, it gave a Drupal white screen of death. I'm not planning on registering again to try it again. Nor do I want to use AI to install and manage my CMS.
That trial form is if you want a desktop installer from the Drupal Association. You can still install Drupal CMS directly with no form by clicking the "Download the Composer package instead" button next to that.
How is Drupal even still relevant?
I honestly think version 7 should have been the last version to carry the Drupal name.
What came after was such a different beast it should have just been its own thing.
I don't have a strong opinion on Drupal (last used it 15? years ago, it was fine) but the people who make don't get to say "Drupal is now light-years ahead of its reputation.". That's what everyone says of their own stuff, just no.
Why wouldn't the makers of something be able to state their opinion on it? Especially an open, collaborative project with many people, and opinions, behind it.
If you disagree with the sentiment, it'd be interesting to here why - that's the sort of information that's extremely useful for makers.
You would probably never see anyone in a (community) leadership role say "we're worse than our reputation", the most humble you'd get is "we match our reputation" (if it's good, not bad) but "we're better than everyone says" just feels wrong to me.
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.
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).
Sounds like you don't have a good use case here though - you don't need editorial workflows, shared asset libraries etc?
No maintenance burden except when you need to add a menu item and have to edit hundreds of pages.
Not really the best timing for this
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.
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?
Unless we're talking about figma-like web apps, Content is usually a different department than development.
I know it's becoming more and more outdated nowadays, but if a magazine or a news website is still written by humans rather than AI they need a way to provide formatted text and media, and preview the output.
On the other hand I should add that i've also seen an upward growth in CMSes like WordPress being used exclusively as Online Editors, with content ultimately being exported trough REST to completely different backends and frontends, like a Firebase/NextJS infra.
I'd argue that content written by non-humans makes this even more important. You still likely have a need for a publishing / review workflow & attribution and a way to ensure standards are enforced and not just left to the end-user's own judgement.
Separating delivery from content management also reinforces this. Set up a governed content / user workflow and then let an agent focus on just the presentation after pulling in the content. I'd say this extends well beyond rest as well. A user interacting with something like a voice assistant in an agent might actually be using many interfaces at once (mcp from the assistant, HTML in a card, WebMCP alongside the HTML, browser open on another device for the human.) When that happens you want one canoninical system for the content.
40% of web sites run WordPress. And there's tons of other CMSes out there as well, so I don't think the majority have moved on.
Moved on from a cms? No, they’re more used than ever before.
websites are still made out of content, I think?
you can be lightyears ahead of your reputation and still be shit.