Drupal is not a CMS

by Larry Garfield

"Drupal is supposed to be the best CMS ever! So why doesn't it come with a simple news or event system?"

We hear that line in one form or another from clients all the time. We also hear it from fellow collaborators within the Drupal community. It's a fair criticism, too. Shouldn't a content management system include some definition of, well, what content to manage? It should.

Drupal is not a CMS illustration

The disconnect is that Drupal is not a Content Management System (CMS), nor has it been one for some time. Drupal is a Content Management Framework (CMF), from which you can build a CMS tailored specifically for your needs.

Drupal has had a long and winding history. It began life as a piece of forum software, in effect; yet another Slashdot knock-off. "The Drop", as it is often affectionately known thanks to its aqueous mascot, quickly evolved into a reasonably flexible content management system, centered around chunks of content called "nodes". That's all well and good, but then it kept on evolving. Soon Drupal was so flexible that some people started to think of it as a framework, not as an application for managing pages on a web site. That Application vs. Framework tug-of-war has persisted for a long time, and has been discussed often.

Around Drupal 4.6 or so, one could still speak of Drupal as a system for managing content. The core system was all about nodes. The contributed module world produced modules that added "news nodes" or "event nodes" or "recipe nodes", along with some canned related functionality like "recent news items", "upcoming events", and so forth. That is where most content management systems stop.

The Drop didn't stop. Starting around Drupal 4.7, key developments such as the Form API, Content Construction Kit (CCK), and Views changed the way Drupal worked; not Drupal core, but Drupal the meta-project. "News nodes", "event nodes", and "recipe nodes" got replaced by "text fields", "date fields", and "image fields", which you could now use to build your own news, events, and recipes to exactly your specification. The "recent news items" block got replaced by "build your own news list however you want," tailored to exactly your specification.

That process accelerated, and by Drupal 7 is almost entirely complete. No one writes recipe modules anymore. They simply don't exist. The assumption of Drupal today is that you will build your own recipe out of the smaller, more atomic pieces that Drupal provides, and then use those same atomic pieces to also build your news and event content.

That's great if you want your own recipe site. It's not so hot if you're expecting to just download a recipe module and call it a day. That is, for better or worse, not what Drupal is, nor will it ever be again. Sorry.

What Drupal is today is a tool for building a content management system for a variety of different needs. That's an important distinction for someone looking to build a Drupal site to understand. Drupal is not a CMS. It is the framework with which you build your own CMS, to your specifications, to suit your needs. It is a Content Management Framework.

In many cases, the CMS you need has already been built. Drupal calls these "distributions", and they are ready-made content management systems built with Drupal. Open Atrium (a project case tracker) was one of the first, but recently there has been an explosion in Drupal distributions (such as Managing News, Drupal Commons, and Open Academy to name a few well-known examples). Not all are fully baked at any given time, but many are quite powerful if they fit your use case.

But what if none of those Drupal-based content management systems suit your need? Then you have the option of building your own. The flexibility of Drupal is in building your own content management system by, mostly, pushing buttons. You define your own data model using Content Types and Fields; you define your own displays using Views and Panels. You define your own administrative workflows using Workbench. You define your own site hierarchy and structure using menus, Workbench Access, Organic Groups, Domain Access, or various other tools.

And when you're done, you have your own Drupal-based CMS, as tailored and honed to your specific needs as you care to make it. But even though it's your own specific CMS, you are still able to get the benefit of sharing the same platform as others because all of the building blocks are the same. That means access to the open source support network, ready availability of Drupal-savvy talent, freely available documentation, and the ability to collaborate with others to push the Drupal platform itself forward. A custom Drupal-based CMS is not an proprietary custom CMS, provided it's built using established best practices. It's the best of both worlds.

Of course, building your own CMS, even with Drupal, is not always a weekend task. For some cases it is, but for most institutions it's a bit more work, and requires careful planning and forethought. That's where Drupal consulting firms like Palantir are helpful. We've built Drupal-based content management systems for dozens of clients, and depending on what you need we can build one to your specifications, help you figure out your specifications, or help teach you to build it yourself.

But whatever your approach, whatever your needs, it's important to understand that Drupal is not a CMS. It is a Content Management Framework: A tool for building your own dream CMS, to your specification, for your organization. Just don't forget that step.


While it is true a Recipe module exists, the current Recipe module is a very 'as is' fixed solution (as far as I know). Unfortunately its not built in a way like Larry says "what Drupal is" currently. The perfect Recipes solution would be built with "the smaller, more atomic pieces that Drupal provides" (quoting Larry) so it's easily adaptable to meet specific needs.

For those interested in 'Drupal Recipes as a Feature', read this blogpost:
(I wrote this over a year ago, please add knowledge if you know about developments that add to this)

I agree with Larry.

For implement cooking recipe, better using generic approach. Not only less module required.. but also the feature is accessible to other content types

With generic approach, for ingredients, we using Double Field.

Recipe module has data multiplier. But if we need data multiplier in other content type, we need to create another one data multiplier. So, we have two similar data multiplier
Isn't it good if we have single and flexible generic data multiplier that will works on all?

It's not that "community plumbing" has been abandoned; rather, out of necessity the plumbing has shifted to smaller pieces.

Plumbing used to mean a ready-made sink with porcelain already chosen, a wood veneer that you cannot change, a width that doesn't fit in your bathroom, and a faucet with a weird dolphin design[*]. That was fine if you liked dolphins, but not so hot if your bathroom wasn't the right size for that sink.

Today, you get a collection of pipes, 3 faucet designs (from different manufacturers, so it's more competitive), hinges to which to attach your own wood paneling (or particle board if you prefer), and a die-cast mold for making your own counter-top. That means you are able to build a sink that fits your bathroom, rather than changing your bathroom to fit your new sink.

Judging by Drupal's continuously-increasing market share, that appears to have been an overall positive change. It's true, however, that is not the case if you don't care what the sink looks like, you just want a place to put water and you think dolphins are cute.

The missing link there are distributions (ready-made bathrooms) and Feature modules (pre-made sinks). Those have been growing in capability, but are admittedly less capable than they need to be. (The ready-made sink market is currently under-served.) Now that distributions are fully supported on Drupal.org there's a huge surge in their popularity, which is great. Much of the work going into Drupal 8 in the CMI, WSCCI, and SCOTCH initiatives is also targeted at making it easier to build ready-made sinks without the hoop-jumping that Features requires.

The catch, really, is that in order to become a better CMS, Drupal must become a better CMF first. Drupal is at a point where the application and product cannot improve without the underlying system evolving to be better technical plumbing. And that's not an easy task, especially when not everyone realizes the transition that is already happening; that transition cannot be reversed at this point. We can only move forward smarter, with a better understanding of the need for really good hinges and wood paneling so that we can build even better sinks.

[*] I'm sure some will see the dolphin as a reference to MySQL, which prior to Drupal 7 was the only database that worked right more often than not. As of Drupal 7, we have support for 5 databases. Whether or not that is a deliberate parallel I leave as an exercise for the reader.

Now that we're integrating w/ Symphony in D8 doesn't that abstract what Drupal is. Since Symphony is really going to be the framework we're building upon? Even more doesn't that make Drupal API a library, and Drupal the product the actual CMS.k

It means just that there will not be any freaks to write modules for Drupal 8.
What purpose to learn all this stuff and write free modules?
I do not see any purpose.
We make money by creating web-sites.
Drupal web sites are commonly made not with a code but with a contrib modules.
There is no place in Drupal for module developer (for programmer) in Drupal.
Learn all this Drupal-Symphony programming complexity? For what?...
It is pity Drupal goes this way =(.

You have a wonderful gift of taking complex thoughts and making them crystal clear. I was given this article by a co-worker who said it was great. When I started reading it I said of course it is great - it is written by Larry!

I am not talking specifically about this article - I am generalizing about all the drupal things you write about. Keep on writing - you are doing great things for the drupal community and I thank you!

IMO you are right. Dries is keen to promote ease of use for simple sites, and Drupal Gardens is oriented to users who need a simple, ready-made solution. However, the need for Drupal to be a better CMF first, which you mention, is only one catch. Another which you hint at is Drupal's complexity. As a small player (in the sense that I have clients who spend hundreds, not five figures, on a website), Drupal requires too much customisation to fit their needs and budget. In the comment above you mention the need for better distributions. My experience is that sooner or later every small client will need, if not custom code, at least guidance from a skilled Drupal site-builder, a skilled debugger (yes, most Drupal sites with plenty of contrib face bugs, sometimes difficult ones), and a lecture on the problems of running Drupal on cheap hosting. Dries (London keynote) spoke about making Drupal both powerful and intuitive. To my mind, making a Drupal distro with a lot of contrib code which offers a CMS which is easy, slick, and cheap to build, run and maintain is an admirable goal but bordering on the unrealistic. Drupal should focus on what it is best at: being a great CMF. Whether such a complex CMF, if sufficiently well designed, could ever spawn the best CMS for the low-budget, low-skilled user, and to what extent it should try to do so, is an open question.

This article is nicely written and does argue the point that most larger Drupal projects use Drupal more as a framework than a CMS, but there are still many “site builders” who do not create their own modules and use Recipes (or other similar modules) to help build the functionality they want. Now that Drupal is integrating so much of Symfony2 into the “framework”, ostensibly to focus on Drupal’s strengths as a CMS, and more functionality has come to distributions, I think the pendulum is swinging back to make it easier to quickly configure a Drupal-based site as an “out-of-the-box” CMS, insulating us from the need for necessarily building each common bit of functionality up from atomic elements.

Even in Drupal 7, I’d have to say that there are many still using Drupal as a CMS rather than a framework and Dries commonly refers to Drupal as a CMS (and Framework and Community)... so I suspect you are (partially) trying to stir up some controversy (buzz) with your announcement that Drupal is not a CMS. ;-) It is certainly a contentious statement.

I just finished a consultation with a small radio station that I built a Drupal site for in the final days of D5. Because of the enourmous complexity of the upgrade process, we now agreed that a far better solution for future sustainability for them is to move to Wordpress. This will in fact be less time consuming than upgrading. True some functionality will be lost but other functionality would go anyway because not all the modules are available.

I think that Drupal needs to offer a better product experience for it to be a sustainable framework for smaller sites. I think its old ethos of no backward compatibility is no longer suitable. I have switched all my blogging to Wordpress because running a blog on Drupal is just too much work.

I think Drupal needs to be split into product / framework streams with different release schedules, compatibility requirements and support timelines. This works perfectly on the Linux desktop - why couldn't we make it work for a CMS?

Part of me wants to laugh and say, "Golly, will Drupal 9 or 10 be the CMF Builder - a tool to build a tool to build a tool to build a website!", and another part of me just wants to cry.

Here is the problem with this CMF vs CMS logic: I'm a developer. If I want a custom CMS, I'll build one. What we've managed to do with Drupal is create something just mind-boggling enough that your standard user needs a developer to build them a CMS with it, and a developer has a super steep learning curve to figure out how to do something they already know how to do.

Your own examples are prefect. 'Recent News' - as a developer I think that is one custom table a form to enter the news items, a mysql query to fetch the data, and a template to display it. I could build it in about 30 minutes from scratch. In Drupal 4.7 it was a menu callback, a new nodetype (no form needed we have it already!), and a hook_block to fetch them and display them in a theme function. But now we're on Drupal 7, and that is a new Custom CCK type, and a View, and perhaps a Panel to display it with. That may seem like less steps, but it so happens that CCK and Views and Panels are not things that a developer knows anything about, and they come with a boatload of abstracted functionality that may or may not work as advertised, may or may not scale, and will definitely be difficult to troubleshoot. Oh, and it still takes me about 30 minutes to build it from the CMS-builder.

In brief, by adding too much cusomizability Drupal has now tipped past the point where it is saving time, it's just forcing me to spend it learning and re-learning it's non-standard ways of doing things.

Sam, I couldn't agree more. It's specious to suggest that Drupal is a CMS builder, as if it were a box of legos. The lego constructs (modules) are simply too complex, and the interactions too complicated, for a non-technical person to master in anything more than a very simple use case. So, as you say, this drives the need for a developer, and the burden is shifted to the developer to understand the intricacies of the modules/interactions to make them work together (and invariably write the glue code required). It's not possible to optimize for "site builders" and developers at the same time, so we're left with a staggeringly complex system that does both poorly. I'm concerned that Drupal will sink under its own weight.

but I do not think it means what you think it means.

Any contemporary CMS that doesn't do most if not all the things you assert make Drupal a 'framework' rather than a 'system' would be outmoded. API, dynamic content models, module/extension system, etc.

As a previous poster mentioned, Drupal is just 'layered' enough (to be poilte) to make it necessary to have a specialized Drupal developer utilize these characteristics. I think this leads to a bit of an echo chamber with the whole (framework vs. system) discussion.

Drupal has grown into a byzantine bureaucracy of software that makes you jump through hoops just to get something basic going, and which other true frameworks do in a way that is more elegant and more usable, both to the developer and the end-user.

Nobody seems to question whether the flexibility that Drupal enables is actually in the right place and accessible to the right people. And the biggest irony of all: the CMS that set out to eliminate middlemen ended up creating an enormous community of middlemen, with their own religious wars and dogmas, their own untouchables, their own imagined set of problems to address.

I think Drupal can be described both as a content management system (CMS) and a content management framework (CMF) - one system which strives to have the strengths of both, without their deficiencies.
Anyway,great article!

Drupal has too much history to try and redefine itself now. There is too much "system" in it to be called a "framework". Sorry but you cannot build a plone admin backend in drupal. Its a system like any other.

The transition I'm talking about it not something I'm suggesting we do. It's something that has, mostly, already happened. We cannot reverse course now and go back to being "just" a CMS without losing most of the gains of the past 5 years.

The point is, rather, both Drupal developers and Drupal customers need to understand, accept, and embrace that shift, and what it means. Approaching a Drupal project means playing to Drupal's strengths, and not expecting it to be something it's not. Drupal is not a blogging platform. It can do blogs just fine, but it's not a blogging platform, and if you approach Drupal as if it were a blogging platform you are going to be very disappointed. That's not Drupal's "fault" per se; it's just mismatched expectations.

When dealing with Drupal, as with any other system, you need to have reasonable and valid expectations of what you're getting. Approaching Drupal core as if it were a turnkey ready-to-run CMS is setting yourself up for failure. That's what Drupal distributions are for. Approaching Drupal as a platform on which to build your dream CMS is how you set yourself up for success.

Having built a site off of COD, even that isn't turnkey or clear in how to execute. The fact is, distributions are more like sets of provided ingredients than full-on recipes.