Drupal, the good parts

I have spent a more than significant part of my career with Drupal, and in the 2010's, I could have been considered an evangelist. But technology, the world and my perspective have shifted, and I feel the urge to structure some thoughts on its state, the parts I still reach for, the parts I would rather not, and where it could go from here.

How it began#

It was the year of 2005. Still at university, I recently read Design Patterns by the Gang of Four, and I thought I knew everything that was there to know. After some projects with [ezPublish][1] I just finished off my first e-commerce project based on my own PHP based CMS [2] that was supposed to become a huge open source success.

We did deliver, but my next thought was: "Can we please not do this again?" Dream of maintaining an open source content management system cancelled ☑️.

Shortly after I changed my job and joined a web agency that also suffered from the same mistakes, but on a different level of magnitude. They were running some high-profile (for Austrian standards back then) websites on a homegrown framework. But without version control. And the process for creating a new project was (I kid you not) clone the entire last project (including the database) and throw away what was not needed. This was the beginning of the social media craze and each of those websites contained some user generated community nonsense. And all the database entries that had been forgotten during the cleanup created some fun (and absolutely not privacy compliant) confusions.

So I swooped in and quickly became the tech lead and Drupal guy. Drupal hooked me with its ability to define data structures by clicking buttons and then storing those in code and re-creating the site from them. Without all the users' names, addresses, emails and credit card numbers! Incredible! Back then those were contributed modules like cck and features. Another big unlock a little later were the rules and panels modules. Drupal was a marvelous crate of lego bricks that I could just re-assemble at will to solve almost any problem.

Cracks are starting to show#

The release of Drupal 8 with the major shift towards adopting Symfony as the underlying library and Composer as the package manager was met with very mixed reception. It even spawned a fork called Backdrop for those unwilling to switch.

Hot take alert: In my opinion, this was the last good and open minded decision in Drupal core. It went downhill from there. The community, paralyzed by politics and bikeshedding, failed to jump onto several important trains.

The mid 2010's brought Javascript frontend frameworks that were way more capable in terms of possible user experiences and developer productivity, but Drupal is stuck with an insane, untyped framework of Twig files and preprocess functions where undebuggable side effects are the primary design principle.

Drupal's entity system is an awesome database abstraction layer, but when you only have a hammer, everything looks like a nail. And the result were content modeling solutions that not only deliver bad editing experiences, but also performance nightmares that we are still fighting against[3]. In the meantime, Wordpress ran circles around Drupal with Gutenberg and the likes.

I already vented about Drupal's API strategy. Almost all implementations, both core and community, follow the "firehose" approach. They just auto-expose all information based on Drupal's built-in data structure meta information. This is very convenient, since it is not necessary to think twice, or, god forbid, write code to expose a stable and easily consumable API. But after recently re-visiting my literature on Domain Driven Design from back in the day, I realized this is the very definition of an anemic model. It means that Drupal's implementation details leak into the consuming systems and forces everything around it to adapt.

Indecision as a framework#

Those deficiencies, while annoying on their own, paint a picture of a consistent pattern. Drupal tries to be a one-stop-shop application platform that does everything. The "Open Source Enterprise Platform" while at the same time still serving the "Dorm Room Social Network" audience it was born out of. And in all the discussions I have been a part of, the latter always had a lot of influence, forcing the target group with the money to compromise. All in the name of the "onboarding experience". If people get to results quickly, they are more likely to adopt the framework altogether. That's not wrong! It worked for me in 2005. But the landscape has changed since then. Web development significantly professionalized, and more recently the "get to results quickly" part is handled by AI agents, which are actually better at writing code than clicking buttons. At this point I would challenge the assumption that Drupal needs a user interface at all.

Cherry picking#

I wouldn't write this long if I intended to only complain. What breaks my heart is how much greatness is hidden under the covers, that most developers do not even get to, because they are blinded by the "Just click the buttons" billboard. I spent quite some time within the Typescript ecosystem, and there are things that I sorely miss.

1. Drupal's fieldable entity system is one of the most capable database abstraction layers I worked with.
2. I took update hooks for granted, only to learn that most Typescript ORM solutions do not support both database schema updates and complex data migrations at the same time. One has to combine at least two tools (e.g. Drizzle + Umzug) to achieve this.
3. Multilingual and localization capabilities are unmatched. That might be due to the fact that those are way more important in Europe than in other parts of the world. But it is hard to find a content modeling system that supports translations of interface, configuration and content out of the box.
4. The authorization system is insanely powerful and extensible. I never faced requirements around permission handling that could not be realized with Drupal. Specifically altering permissions within other parts of the ecosystem without having to fork those.
5. The Drupal Security Team has a really solid process and does an incredible job dealing with vulnerabilities both in core and in the contributed module space. As far as I know this has no equivalent in the PHP space.

A sobering reality check#

Re-reading my own list, I have to admit something uncomfortable: most of these benefits are covered just as well by Symfony or Laravel. Doctrine handles entities. Both frameworks have solid migration tooling. Their localization layers are perfectly capable. The authorization systems in both are extensible enough for almost any requirement I have ever run into. So am I just nostalgic?

The one thing that genuinely has no equivalent anywhere else in the PHP world is the Drupal Security Team. The process around responsible disclosure, coordinated releases, and the level of care for the contributed module space is unique. That alone is worth a lot. But "we have a great security team" is a thin reason to pick a framework for a new greenfield project in 2026.

What I would actually want from Drupal#

If I could nudge Drupal's trajectory, I would aim it squarely at agent interoperability. The cherry picks above are not just nice properties on their own. They are the exact building blocks that an agent-driven workflow craves: a strong data model, deterministic migrations, multilingual support, fine-grained permissions. The pieces are all there. They are just packaged for human site builders instead of LLMs.

Two concrete things that would unlock a lot:

1. A strictly typed, programmatic configuration layer. Drupal's YAML configuration is great for diffing and version control, but it is a minefield for anybody (or anything) writing it from scratch. Agents need types, schemas, compilers, fast feedback loops. Wrap the configuration system in a typed API that catches mistakes before they hit the database, and agents will write reliable Drupal configuration all day long.
2. A non-anemic API as a first-class citizen. Stop auto-exposing the internal data model. Provide tooling (the GraphQL module for Drupal with custom schemas already points in this direction) that makes it easy and idiomatic to design a domain-focused API. Drupal would stop leaking its idiosyncrasies into every system it touches and start being a good neighbour in larger architectures.

Neither of these is a moonshot. Both are well within reach of the existing community.

What Drupal is actually doing#

Unfortunately, that is not where the energy is going. The recent DriesNote at DrupalCon Chicago 2026, the 25th anniversary edition, made the direction very explicit: "use AI to prototype fast, then use Drupal to build systems that last." Translated, the two big bets are:

• Integrating AI into Drupal. Drupal Canvas (the artist formerly known as Experience Builder) shipped as the default in Drupal CMS 2.0, paired with Canvas AI. Describe a page in natural language, and an agent assembles it from your component library. The Context Control Center keeps generated content on-brand. There are content-monitoring agents that watch published pages and update them automatically.
• Doubling down on the editing experience and page building. Drupal Canvas is a no-code visual builder. Site Templates and a curated marketplace are meant to "raise the floor" for new Drupal users. Which is exactly the area where vibe-coding frontends are eating everybody's lunch. "Describe a page and get a page" is table stakes for any Lovable or v0 clone, and they are not burdened by twenty years of Twig.

The AI Initiative has rallied an impressive amount of contributors and sponsorship money in record time, and almost all of that capital is being spent on assistants inside the Drupal admin UI. And that's the problem. If Drupal just exposed it's capabilities in a structured way, nothing stops Claude & friends to just pick them up and do all the things described above. The resources allocated for building this into Drupal are wasted. Unless of course, the primary goal is to vendor-lock as many users as possible.

To be fair, there is also real work happening on the MCP front. Drupal ships both MCP client and server modules, and the framing in some sessions is explicitly about Drupal being a good citizen in agentic stacks. I am genuinely glad this exists. But it lives in the corner of the roadmap, gets a fraction of the keynote airtime, and is positioned mostly as "Drupal as a data source for external agents" rather than a peer in a larger architecture. The center of gravity is still very much the admin UI.

All of this optimizes for the audience that Drupal grew up serving: the site builder, the small team, the agency that wants a click-together CMS. I get the appeal, and I understand the gravitational pull of the existing community. But the world has moved on, and the "Open Source Enterprise Platform" audience, the one that actually pays the bills, needs very different things.

Closing thoughts#

I am increasingly convinced that our job over the next few years is mainly to put the right levels of determinism into otherwise non-deterministic, LLM-based systems. Schemas, types, validators, strict APIs, deterministic migrations: the boring infrastructure that lets us trust the output of a probabilistic machine. And users will interact with our systems less and less directly. The interface will not be a CMS admin panel, it will be a conversation with an agent that talks to our systems on their behalf.

Drupal core, almost by accident, contains some of the most capable parts for exactly that kind of world. The fieldable entity model, the update hooks, the localization layer, the authorization system. All of it would shine in an agent-first architecture. But the trajectory is pointing somewhere else.

I still reach for Drupal. Last year I built a large project on it (a multi-user data storage backend with extensive content modeling and fine-grained permission management), and it was a great fit. The fieldable entity system, the authorization layer and the migration tooling did exactly what I needed them to do, and I would pick it again for the same kind of problem tomorrow. I just hope that a few years from now, this part of it has not devolved while the focus was set on building yet another chatbot.