The Twilight of the CMS

[neotoxic]

I found this article, which whilst I don't agree with, think it make some interesting points. Then notion that the application is an API and the communication with the various elements is that of independent applications is an interesting one that has parallels with ProcessWire I think.

I was wondering what your thoughts were.

http://labs.talkingpointsmemo.com/2011/07/the-twilight-of-the-cms.php

[Adam Kiss]

I apologize, I somehow missed what the big news are. It's written in fairly glorified way about itself, bu the only thing I noticed so far is another CMS with different UI, this time with another in-page editing, though I must say this type of inpage editor looks fairly well working.

Then again, whole blog post is about backend, while demo shows only that it's possible to make working in-page editor, allowing some modification with few clicks.

[neotoxic]

Oh I agree.. whilst I am sympathetic to the sentiment expressed in that article, I think there revolution is just one of semantics.But the idea that the components are all individual applications is an interesting one, and as I say not dissimilar to how ProcessWire delivers its infrastructure.

[ryan]

Thanks for the link. It sounds like they've gone buck wild with the adaptor pattern because they were stuck between a rock (MoveableType) and a hard place (needing to do more than an elderly blogging engine can do).

I think that the author accurately describes the state they got when freed from the shackles of an old CMS they've been using for a long time. But I also don't think the author presented a good understanding of the overall CMS landscape outside of the platform they were using (MoveableType) and perhaps less so WordPress and Drupal. The article would be more accurately titled "The Twilight of MT for TPM". Though what they've really done is just move MT to a nursing home while keeping plugged-in to it's data.

As I understand it, their treating everything as an "application" is just their way of saying they are treating all their local resources as web services providing a common API to it all (adaptors to things like MT). These are plugins/modules that have a common API (like a Markup* plugin in PW).

For TPM's needs, having that extra layer of abstraction reduces their dependence on any one system. A desirable thing, especially when the main system (MT) is pretty ancient. So they've shifted their dependence from open source MT to their own system and presumably one or two coders. (incidentally, this is the opposite shift of dependence I would usually recommend). Those coders will now write adaptors rather than mucking about in MT. Those coders now have a proprietary system and secure jobs. I would hate having a job to fiddle with old-school MT all day, but clearly the management wasn't willing to kill off MT (otherwise I'm sure they would have long ago). So if this is the coders' answer for how to do more interesting work without killing off MT, then I applaud them for it.

Getting down into the details, the intentions sound noble and well founded. But practically speaking, we're talking about more layers and more complexity. Perhaps that provides the right balance and level of comfort for their CM needs. But their needs are pretty specific, and to suggest this is the right approach for others I think is missing the mark. I suspect they would be better off if they'd just standardized on a more modern and capable platform (rather than an elderly blogging engine). Newer platforms would give them much of the perceived benefits of their approach and be far less costly and easier to maintain. With another modern CMS, they would accomplish the same thing but hopefully not have to develop everything themselves.

Setting aside the fact that most popular CMSes have chosen their plugin language unwisely — Moveable Type uses Perl. Drupal, Wordpress and Joomla use PHP.

This is where I started questioning the author. Apparently PHP is an "unwise" language. Yet it's powering many of the world's largest, highest-traffic sites (Facebook being an example). No other language can come even close to the scale and scope with which PHP has been successfully used on the web. Regardless of whether one likes PHP or not, it has gotten the job done at a scale not ever seen before. Given that track record, I believe that saying PHP is "unwise" is a statement that significantly lowers the credibility of the author.

the plugin model aches at scale: popular plugins become abandoned plugins, energies move elsewhere.

This statement has nothing to do with the "plugin model". It has everything to do with supply and demand. Their solution is to move their "plugin model" in-house. If they are paying to create their own plugins then they decide when to abandon them rather than someone else. Cool, but it's still economics.

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.

Perhaps that's how it works in MT (I don't know). But this is not how it works in WordPress, Drupal, ProcessWire or any quality open source CMS.  The author is describing a patch system not a plugin system. If the plugins needed to know about each other it wouldn't be a very good plugin system would it? I don't think the author knows what they are talking about in this case. But if that's their definition of plugins, then apparently that's why they aren't calling their plugins "plugins".

I think that a lot of good points are made in this article, but only towards reinforcing the direction that many modern frameworks and CMSs have already gone to. And they would probably be better served by investing their efforts into such systems. I do like their solution for adapting to their legacy systems, but this is hardly new. I enjoyed the article but am disappointed with the way they've presented the ideas as something they are most definitely not, i.e. "The Twilight of the CMS", "A New Hope", "The Baroque Road Ahead"... come on. Somebody's been using MT for far too long...

[Adam Kiss]

Small OT: Ryan, I did not see this coming from you. It's "they're" or "they are", not "their".! BAH

As I understand it, their treating everything as an "application"

[ryan]

Try writing that many words fast and not making a typo or two.

[apeisa]

Great post Ryan and interesting discussion, thanks for bringing it up Neotoxic.

Perhaps that's how it works in MT (I don't know). But this is not how it works in WordPress, Drupal, ProcessWire or any quality open source CMS.  The author is describing a patch system not a plugin system. If the plugins needed to know about each other it wouldn't be a very good plugin system would it? I don't think the author knows what they are talking about in this case. But if that's their definition of plugins, then apparently that's why they aren't calling their plugins "plugins".

I agree (I haven't seen problems author of the article is writing), but there are some problems. If CMS is not flexible enough for site builders then it means that you start looking for plugins for every need you have. You know, things like "product listing plugin" or "phonebook plugin" etc. Take that approach and soon you have 35 plugins installed. Now add one very poorly coded plugin which broke something that few another plugins needs. After that you have few non-working plugins because of one badly working - and you do not have a clue why that is happening (you start uninstalling those plugins, one by one and looking if all starts working again). This is the scenario where many non-developers-but-active-site-builders end up when they build and maintain sites.

That is one of the reason I think where "custom content" cms like pw, ee, symphony, drupal (and if I remember also wordpress 3.0+ in some way) is requirement for bigger sites (and by big I mean that they have lot's of very different kind of content). If you respect your content, then you have all doors open. Of course there is many many differences between those systems in other areas.

[almonk]

Really interesting discussion.

The 'solution' arrived at here is very, very specific to the nature of the content management needs of the business. In a way I love the idea of such a system so perfectly suited to the CM style, but clearly it requires a huge amount of investment of time, money and resources that isn't within the reach of most small-medium businesses.