"Drupal, Wordpress and Joomla use PHP. — the plugin model aches at scale: popular plugins become abandoned plugins, energies move elsewhere. Plugin A works great, plugin B too. However, they weren’t designed to know about each other, thus leading you down a rabbit hole of forking and mending. A few years of use later, you are left with an unmaintainable tangle of ad hoc code written by an all-but-unknown cast of programmers."

This is true of Joomla, and to some extent Wordpress, but as someone who makes his living using Drupal, this statement is patently false and indicates that the author isn't truly familiar with the systems he's criticizing.

The cast of characters behind most Drupal plugins (modules, in Drupal parlance) is well known and most have been iterating their plugins for four to six years (or more). Drupal.org serves as the sole repository for plugins, providing usages statistics, notifying users of upgrades and patches to modules, serving issue queues, and generally keeping the Drupalverse running quite smoothly.

Drupal plugin A and Drupal plugin B are designed to know about each other, at least indirectly, because they use the same fundamental elements (the menu system, the hook system, common APIs) to manage data.

I'm not going to claim that Drupal is "Wordpress easy" to install, or that you'll just sit down in a day and master the system as it's as much a RAD framework as it is a CMS. It's big, powerful, and flexible, and these traits are the natural enemies of "easy."

FWIW, I'm not a core contributor or anything like that, I'm just a guy who's made a hell of a nice living using Drupal.

Drupal achieved this by requiring modules that get hosted on Drupal.org (the most popular site to find modules) be reviewed before they're published. Part of the review process requires verifying that the module (a) doesn't duplicate other modules and (b) doesn't belong as extra features added to another module. If your module doesn't work with the other modules on drupal.org, it will never be published. You're required to collaborate.

It works fairly well, although the review queue is long and you get people whining about how their module really deserves to be published.

I don't disagree with any of this, but would like to add that just because a module get published on drupal.org does not mean that (a) it works or (b) it's well-written.

The mainstream modules... the common ones used on thousands of sites, tend to be solid. There's a lot of half-baked crud once you get into the smaller or lesser-used ones.

This is true of any software library or framework that allows plugins, but it doesn't mean that the core idea itself is wrong.

For example, jQuery has dozens of gallery/slideshow and lightbox clones of widely varying quality, but jQuery itself is a brilliant foundation for Javascript development, including its plugin structure.

Indeed. I try to do rigorous reviews of modules (too much spare time at work), but I don't have enough time to install them and test every feature. I just check for obvious security holes and API abuses. And of course, once you've published one module you can make more without any review at all.

I was once tasked with upgrading a Drupal instance and while I surely don't have the experience you do I have opposing feelings about this. Some of Drupal's more popular plugins are certainly well maintained, but for this case (and I imaging somewhat commonly in the industry) they used numerous obscure plugins, some of which were only in "beta" stage. In checking the repo logs of these plugins it seemed as though some hadn't been maintained for years.

There is also no database restrictions placed on the plugins, so they could literally modify any database schema. Not only do plugin A and plugin B know about each other, they are required to know about each other to function correctly; and I see that as a problem. While it can be argued that this is part of what gives Drupal its power and flexibility, I see this power as a very dangerous thing in a community of its size. It almost requires developers to put out quality plugins which is often not the case (for Drupal as well as any other community driven software products).

It's also common sense to pick the right plugins for the job.

There are a lot of modules which have been deprecated or which are no longer maintained, sure. However, this doesn't mean that Drupal is in any way bad.

Let me present the case of Ubercart as a counterpoint. It was the upcoming, loved by many e-commerce system built on top of Drupal. When I first looked at it in 2008, it was still in alpha. But it looked like having solid devs and good community behind it. So I jumped on it, built my site around it and even developed custom modules for it.

Fast forward to 2010. The project has forked and the main dev has gove over to develop the next generation of Drupal e-commerce system which is a completely separate project. It is only being developed for Drupal 7 and has no migration path from UC. I heard that someone from the original team is still continuing to work on Ubercart but the site has had no updates for about a year.

To put it in perspective, this leaves me with 2 options. One is to live with the old UC (which still lacked a lot of stuff since it was pretty much work in progress) and keep investing further in developing on it while knowing that underlying platform is dead. Or I can jump over to Drupal Commerce which would mean I would need to move to Drupal 7 which would mean porting all the rest of my custom development (which has nothing to do with e-commerce part) over to D7 which I had no need to! For those who do not know, Drupal does not maintain backward compatibility between major version upgrades.

Having said that, I don't have any gripes with UC devs. I have benefited from their hard work and thank them for that. I am just pointing out that even Drupal ecosystem is vulnerable to what the original article said.

"FWIW, I'm not a core contributor or anything like that, I'm just a guy who's made a hell of a nice living using Drupal. "

Would you mind expanding on that. Do you offer a plethora of services or focus on one or two things? A friend of mine set up shop building small sites for local business with drupal and is always tell me how great it is.

Sure. Our niche is working with ad/marketing/traditional media agencies, SEO firms, and design groups to provide the technical muscle they don't have to get beyond "five pages and a contact form." So what we do is pretty focused: we don't do design, we don't do marketing, we don't do offer SEO (we build very SE friendly sites, but we're not doing keyword research or running PPC campaigns). We're just engineers/developers (if you can call anyone that works with PHP for a living an engineer). :)

I'm not sure the problem is necessarily Drupal, but I tend to agree with the post's authors that a Drupal written in something other than PHP would be a nice thing to have. Specifically Python would be really nice.

Why? Look, I hate PHP as much as the next passionate software developer. I did PHP full-time from 2000-2005 until I couldn't take it anymore. I spent a fair amount of time with Drupal and it was technically very impressive even though ultimately it was not for me because the tradeoffs were not where I wanted to be as a developer.

The thing is, what a CMS does is cater to a site which does not have the budget for custom software. A system like Drupal gives a tremendous amount of bang for the buck, and of the open source CMSes, it's hook system is definitely the most powerful once you really understand how to drive it. In the end you're hitting the Drupal sweet spot when you write just a bit of glue code here and there to tune the functionality of existing modules to what you need.

In short Drupal and other CMSes let you build sites with a scope of functionality which would be impossible to do custom development for. In this type of market cost is such a factor that anything less ubiquitous than PHP would be a strike against the system. Furthermore, as the number of modules grow, you need a very large community to keep everything working smoothly, so you don't want to go with a language that has lesser adoption.

Personally I can't stand CMSes because I feel like the abstraction is at the wrong level. To me it's mediocrity by 1000 tiny assumption mismatches. Using Rails or Django I feel like I can craft a minimal, excellent and highly tuned UX exactly to my vision with a better language and lower overhead. Making a CMS in Ruby or Python doesn't address the root pain of living within a heavy and immobile scaffolding. There's a reason you don't hear much about the many open-source Rails CMSes that have been floated over the years.

I don't know about Drupal - I would tend to agree it's a little too cumbersome to the point where I would rather write something with a good framework like Django.

But WordPress is really nice, aside from PHP, and my once-off design-a-simple-website projects that use it would be a lot simpler if there were something similar that had a better language. PHP does add a significant amount of gymnastics that make plugin development more difficult.

I don't mind living with a heavy and immobile scaffolding for small projects - but using bubblegum, shoestring, and when necessary sauter to put what little additions I need on is a lot more annoying than just having a clean, standard set of screws and brackets. WordPress especially has a decent set of screws and brackets, but at the end of the day it is PHP and I see a lot of stuff that looks suspiciously like bubblegum.

As for Drupal, I'm not saying I have an incredible amount of experience in it, but taking it for granted that it's a useful framework, I imagine it would be more useful if written in Python or Ruby. Also, I don't buy the argument that PHP is easier to find - I think you would actually have to go out of your way these days to find a place that had PHP but not Python or Ruby available. Certainly all the cut-rate behemoths like HostGator support it.

The problem you see with these applications is that they are bad PHP, not that they are PHP.

If you would, go take a peek at the Symfony2 framework. It's positively brilliant code, and it's PHP--Fabian Potencier and friends are excellent programmers, and they write excellent code in PHP.

I'm currently in the process of building a migration path from our two different older PHP frameworks (MidCOM and Midgard MVC) to Symfony2, and I've really been impressed by the community.

They seem to be very receptive to new ideas, and passionate about code review. I've received lots of GitHub comments on my bundles even though the commenters probably would never actually use them.

And when I found an issue in Symfony2 itself that made integration with AppServer-in-PHP harder, Fabien fixed it within the hour of getting reported.

I tried to address the issues of the PHP CMS space here: http://bergie.iki.fi/blog/my_secret_agenda_for_php_content_m...

I am actively contribute to Drupal and I will say just what you said - OP did not invest enough time to claim what he claimed regarding Drupal.

+ Community which is not just open source, but just open. Which tends to make their modules to work with others. And it is pleasure to contribute to community like this.

The person who wrote that article doesn't seem to have such great technical skills. He came off as the classic blogger who feels he has to share his opinion about everything without having taken the time to actually write some PHP code, to build a site with Drupal or otherwise.

I find this interesting because TPM's solutions reminds me of the classic UNIX "pipes and filters" strategy - a series of small components with well-defined inputs and outputs that can be strung together to produce a sophisticated result. (Of course, "small", "well-defined", and "sophisticated" could be relative terms.) The pipes and filters "API" was plain text transmitted through stdout.

It also strikes me as an example of software development becoming more deeply embedded in media companies. It's not an accident or a coincidence that most content management systems work on the framework-with-plugins model. Dedicated software developers build the framework, and it's expected that organizations who use it only have the technical chops to deal with plugins. TPM's architectural change is also a change in the amount of development work they plan to do - they're saying that they can afford to rewrite/develop/debug/etc. 10% or 20% (percentages are arbitrary) of a CMS-size framework and string those components together, rather than work with the 2% of a plugin and sprinkle it on top of the main 98%. They've moved up the food chain in the size of their internal development.

I think the natural next step of "UNIX pipes and filters" is Flow-Based Programming (http://en.wikipedia.org/wiki/Flow-based_programming). Processes can have multiple named input and output ports, and data flowing between them can be objects and other data formats.

In currently building an Open Source FBP tool called "NoFlo" on top of Node.js, and at least the initial results of building websites with it are promising.

This is definitely the direction i see things going.

Node.js is also perfectly suited for it, and I recall hearing that it's also on the core team's mind.

Here's my project: https://github.com/bergie/noflo

Blog engines are a subset of CMSs. They're supposed to be restrictive - that simplicity is part of their value. If they wanted a CMS that would allow them to add their own types of content, they should have gone with a CMS that was more "framework" than "application"

That's what I was thinking, especially when I read this part:

"The CMS has to be everything to everybody. Wordpress has to optimize for both the cat-picture faithful and the ring-bejewled, hair-fisted mogul. Moveable Type has to work whether you are running a lad mag or poetry journal. This is an impossible proposition."

Expecting every (?) CMS to be the end-all solution to every possible content situation is ridiculous. It would be nice/neat but that doesn't seem to be quite how it works—is that idea akin to expecting every vehicle to be able to perform every type of situation available? Expecting your family sedan to also be the workhorse carrying materials and whatnot?

What if you only wanted to ride a simple bicycle down the street and not have to worry about a more intricate/heavy one? I use different CMS for different things though admittedly, that makes it harder to master one in particular.

http://www.thesecretary.org/ - For portflio type sites. http://staceyapp.com/ - For incredibly simple sites. http://textpattern.net/ - For most other things.

I do feel as if CMS have kind of stagnated for a bit and am a little tired of most so I'm thankful for the author bringing Netsta to my attention—it looks interesting.

It sounds like Separation of Concerns[1] applied on a larger scale. Software is easier to manage and more flexible if each piece does one thing and does it well, with as little overlap with other components as possible. This is what makes OOP a good system for designing large programs. I helps people separate out the various components so that maintenance is of many small pieces with clearly defined boundaries instead of one large piece with none.

Separating out these services into their own "apps" is like splitting up classes. It's a natural and good way to increase maintainability and flexibility.

[1] http://en.wikipedia.org/wiki/Separation_of_concerns

Exactly the approach I'm pitching to CMSs in here: http://bergie.iki.fi/blog/decoupling_content_management/

This is roughly what Ars Technica was doing before I left, I think moreso now. The Movable Type "post" interface was relegated to "the box people write text in", which was then pushed into the app that handled rendering a site.

The world of Content Management Systems is definitely an awkward place to be in, However, I don't think that the notion "The CMS Is Broken" is really justified.

I think the first major problem with CMS' is that people expect them to be the end all be-all solution to their site and content needs. Clients expect them to be an intuitive cheap publishing platform that will magically format, organize and display an endless array of content and content types, while developers expect them to be fast, easy to extend, scaleable, lightweight and fit a theoretical "goldilocks zone" of adhering to conventions but still being flexible.

To fix the client problem, clients need to understand software does not create good content for you. Content needs to be curated and software is there to help with the heavy lifting. Instead of forking out X amount of money on software, spend half that and spend the remaining half on writers, photographers and people to make your content great.

As for the software/development problem, each specific case can require a different platform. Just like one specific programming language is only one tool in the box, one CMS follows the same pattern. Educate yourself about all your tools and explain the pros/cons to the client before making a decision, but in the end, isn't that what were being paid to do?

Sorry if my comment is a little more about the business side of things and not necessarily about the CMS itself, but I feel its a pretty important point on this issue

Definitely an interesting perspective from the media industry. Although the pattern described is a relatively common pattern across a lot of "webapps-at-scale." For example, the CTO of Trip Advisor recently talked about how Trip Advisor is a series of distinct services exposing APIs that all run separately and are pulled together for a page render[1]. At some point most growing web apps simply outgrow the ability to be a single monolithic PHP/Rails/Python/whatever app and need start breaking things up.

Although, it seems like TPM is seeing benefits from this that go outside the typical reasons folks start to go this route, like outgrowing a single relational database or wanting teams working on different components to be able to work and deploy independently of each other.

[1]http://highscalability.com/blog/2011/6/27/tripadvisor-archit...

Wow -- this really stuck a chord with me. My startup's product is a CMS. Before we build the CMS, we built the API:

http://www.gethifi.com/blog/first-we-built-an-api-then-we-bu...

That said, I didn't buy everything he said. We've built a farily agnostic API, very much like he described. That said, it's not Mongo, it's not MySQL and it's not CouchDB. It's impossible to build something that is 100% free from constraint and trade-offs.

Blog Engine CMSs are restrictive because they are Blog Engines! You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video.

The simplest way to design an API, is to use an existing one. I work with a CMS where JSON documents are posted using the WebDAV protocol. Settings for documents and folders are all set with the PROPPATCH verb. The WebDAV protocol has defined API's for ACL, versioning and namespace management like delete, move, copy.

Info about Vortex CMS (in Norwegian): http://www.uio.no/tjenester/it/web/vortex/

Sounds very good. Would the DAV (REST) APIs be accessible for something like https://github.com/bergie/VIE ?

Yes it probably would. The API is also accessible from client side javascript. So you could create admin pages in 100% javascript like in HiFi.

Admin pages are one thing, but with VIE you can make content also editable right where it is. See for example what we did with Midgard:

http://bergie.iki.fi/blog/introducing_the_midgard_create_use...

I really like the constraints you set on your project: "Build a CMS, no forms allowed". Aloha and other wysiwyg editors can hide the CMS almost totally. Using RDFa to store content is not a bad idea.

If you're interested in integrating VIE into that system, then the EU-funded IKS Project might be able to help you with that: http://www.iks-project.eu/get-involved

For the content management API, have you looked at Content Repositories? There are pretty good specs for standard content management APIs for Java (JCR), PHP (PHPCR) and Node.js (NoCR).

The REST API alternative, CMIS, is unfortunately a bunch of committee-designed mess.

Hey Joel, I remember seeing this post on HN ages ago and tried to find the link recently :) I wanted to show this "api first" approach to someone who was building an XML API for Flash sites. I showed him the Decal API [1] but wanted to give him this as an example a well, thanks for reminding me!

[1] http://www.decalcms.com/page/Decal_API_Quick_Start_Guide

> You can see that his system has its restrictions too as he enters a pixel based headline size in the demo video.

The fact that he specifies the size unit actually suggests that the system would accept others. It's basically CSS after all.

I mean in the sense that he is storing pixel sizes as opposed to some semantic information. This implies either:

1. An elaborate system of decoupling styling information from content via metadata. (i.e. in situation X, this document's headline should be 20px) Their approach would be pretty interesting here. How could this be preserved as their design/layout evolves with time?

2. He was just indicating that headline in position X be 20px, communicating with the layout.

3. He was hard-setting it to 20px.

It's probably #1. So if, as he says they switch layouts and output to tumblr, how would that work? Their answer might be a lot of manual work, or it could potentially be something really clever.

The semantic information is already in the selector that pops up, e.g. '.headline'. I don't see why they need to store anything elaborate to make that portable. The scope of the change (document, document type, section, site) isn't shown but presumably it defaults to 'type'.

BTW the in-place edit features remind me a lot of this[1] use of Deface[2] in Spree[3]

[1] http://www.youtube.com/watch?v=qjgQHzYcxIQ

[2] https://github.com/railsdog/deface#readme

[3] http://spreecommerce.com/

"Our new system will simply wrap the MT database in a cached layer and incorporate its content. Our new gallery app — currently active on the site — creates slideshows, writing its changes to central datastore as well."

Also known as "now they've got two problems", or in this case, four. Or I don't understand it - it sounds as if they have introduced another layer between frontend and backend, which probably increases complexity.

The road to hell is plastered with abstractions...

Well there are certainly tradeoffs. We do have more apps that can fail. Then again, when one does start to choke, as will happen, the others don't die. So if Baroque locks up, or starts to churn, or I do the ol rm -rf / all that is impacted it our ability to press frontpages until Chef can mint us another Baroque.

Also, there's not, so much, another layer between frontend and backend as there is a multiplication of frontends. It certainly may get us into trouble. Luckily, we already were in trouble and, worse case scenario, we all learn a lot from the experience.

The hell-road blacktop is something we are trying to tear us by substituting the abstract relation of CMS to site for a closer isomorphy of app to function. Who knows? Might work.

Wasn't this exactly the problem that Django was originally trying to solve?

Indeed, Django was made for news rooms!

Certainly the whole "homepage is an app" concept maps perfectly onto Django's ontology of projects and applications.

The API, however, is not something that's built in. They might want to take a look at Ellington (http://www.ellingtoncms.com/).

I like the feature-as-app paradigm, but the article says nothing about the underlying API. I have used a CMS the last couple of years at work, where documents are stored as JSON files on the server using WebDAV protocol, which off course is totally REST based. Access control is done using the PROPPATCH verb. The CMS is named Vortex, developed at the University of Oslo and has an open sourced license. Too mee this API seems to function better than the usual custom made REST based API.

The most complex piece of software I've worked on was a CMS. I spent a lot of time doing competitor evaluations, and, without fail, the only successful implementations were using small products in small workgroups. Trying to solve the "enterprise" problem always failed, both because the software became stupid complex and the processes became even worse.

I don't think its an intractable problem, but the people issues surrounding it make it a hugely difficult one.

His discussion of editors' thought process about CMS tools and making site parts from apps sounds suspiciously like the reasoning over at the Lawrence Journal-World newspaper. I'm curious why their solution wasn't mentioned.

Blaming technology isn't going to change the fact that journalism is still broken.

Folks like John Gruber and Matt Drudge make a ton of revenue by serving their readers. They have simpler technology than everything stated in this article.

You'd be hard-pressed to find an entity less representative of the 'old media being outflanked by the young hotshots' stereotype than TPM.

I think this is somewhere that highly adapted mini-frameworks could take hold.. something like Padrino for Sinatra, yet slightly more publishing friendly.

Holy shit people still use Moveable Type?