

The CMS Is Broken. - yahelc
http://labs.talkingpointsmemo.com/2011/07/the-twilight-of-the-cms.php

======
crikli
"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.

~~~
lukeschlather
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.

~~~
dasil003
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.

~~~
lukeschlather
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.

~~~
eropple
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.

~~~
bergie
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.

------
ejames
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.

~~~
bergie
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.

~~~
vertice
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.

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

------
shib71
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"

~~~
dorian-graph
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.

------
Periodic
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>

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

------
mrkurt
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.

------
brock790
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

------
mikeocool
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...](http://highscalability.com/blog/2011/6/27/tripadvisor-
architecture-40m-visitors-200m-dynamic-page-view.html)

------
JoelSutherland
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...](http://www.gethifi.com/blog/first-we-built-an-api-then-we-built-a-cms)

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.

~~~
thomasfl
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/>

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

~~~
thomasfl
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.

~~~
bergie
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...](http://bergie.iki.fi/blog/introducing_the_midgard_create_user_interface/)

~~~
thomasfl
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.

~~~
bergie
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>

------
Tichy
"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...

~~~
esmooov
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.

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

~~~
fdb
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/>).

------
thomasfl
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.

------
SoftwareMaven
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.

------
mikx
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.

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

------
Terretta
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.

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

------
dools
Yep, we here at Working Software _definitely_ think CMS is broken ;) [1] but
mostly because of the deployment system and reliance on "designMode" word-
style editing. Basically, we hate "plugins".

[1] <http://decalcms.com/mockups/>

------
tedsuo
Holy shit people still use Moveable Type?

~~~
vladsanchez
NPR.org still uses it. And it's a great example of MT's potential.

