CMS: Interesting History, Powerful Future

Posted: 2012-04-24
Category: PHP

As a CMS developer on the PyroCMS team, a common problem I have to deal with on an almost daily basis is peoples strange fear of using a CMS as a base for a project. People often suggest the tools of my trade are not appropriate, are only for "small sites" or should not be used as a base for an application. I know there are plenty of awful content management systems around, but I propose a few rules for CMS developers to follow so we can shirk this dark cloud that hangs over us.

In many places I will talk about from the side of an end user - often a client, or whoever is in charge of looking after the website, and the side of a developer - who wants to (or is being paid to) extend and improve the system.

CMS History, from where I stood

I've been building sites since I was about 12. I started off messing around with phpBB which was just a bulletin board but it started getting all sorts of hacks to allow certain forum posts to be pages. Weird, but it was better than making everything with HTML.

PostNuke and PHP-Nuke came along and blew that approach out of the water. Suddenly there was a full on CMS that could do... ANYTHING. Sadly it was an ugly piece of crap, had a horrible code-base and building modules for it was a chore. It wasn't the fault of the team, it was 2001 and who knew any better?

I used it for years - and even got involved with the PNphpBB team who tirelessly fought to keep phpBB and Postnuke integrated - but it was terrible. Drupal and Joomla were other solutions to the same problem, but were still way too complicated for the every-man and still lacked the clean MVC core, meaning that more PHP soup was to be found. For both end users clicking around on the backend and developers trying to build something up, it was not easy to learn how to work with these beasts and for anyone not interested in paying for training, other solutions were still sought after.

Simpler "blogging platforms" started springing up. WordPress and pMachine came along to save the day. Suddenly we had awesome blogging systems that could blog, and... well write blogs... They were cool, but people wanted to have a blog AND a site, so these systems started allowing certain posts to act as pages. Weird, seems a bit like that old phpBB approach but... lets go with it for now.

Blogging platforms get Add-ons! What better way to stop them just being about Posts and kinda-Pages-almost, now they can do ANYTHING! They have e-Commerce solutions, and all sorts of other bits strapped to the side. Getting people to build part of your application for you is fun, because you don't need to write it yourself. Sadly that is only a good thing if the code is any good, and that relies on the API provided to the developers being well thought out, wide reaching through the system and done with clean OOP code.

Sadly this is not how WordPress does things.

The Wrong Way

While everything in WordPress is a post in a weblog, they can extend functionality with "Plugins", but let's take a look at the WordPress definition of a Plugin:

WordPress Plugin: A WordPress Plugin is a program, or a set of one or more functions, written in the PHP scripting language, that adds a specific set of features or services to the WordPress weblog, which can be seamlessly integrated with the weblog using access points and methods provided by the WordPress Plugin Application Program Interface (API).

Source: Writing a Plugin

To give the WordPress community their due they have managed to integrate a LOT into their "weblog". Using Plugins they can do all sorts of crazy stuff, including e-Commerce and building entire social networks. That in itself does not mean they are doing it right and I come into contact on a daily basis with people who are jaded against developing with CMS systems because of this, even some friends in the start-up world who are painfully trying to find funding after their first prototype got smashed together with WP-tape and string. With a little bit of hacking you'll soon find anything is possible, for more evidence of this check out the There I Fixed It! blog, topically enough on WordPress itself.

The Even Wronger Way

The best "I Fixed It" was working for Hargreaves Lansdown when they put in a £500,000 Content Management System to replace an in-house CMS. Sure the one we used had basic MVC, could use just a TPL or PHP and worked perfectly, but it took the Marketing team a few hours to make text changes and that meant we had to ditch all of our well structured code and use some shiny does-everything CMS to help them change text quicker...

Almost straight away we pointed out to the developers of the CMS that although we had all sorts of "Assets" available to us, there was nothing to actually access our content. They came up with the solution: the "REST Resource JavaScript Asset". This allows us to consume a REST endpoint, handle the response (XML only) with ECMAScript (not even any known version of valid JavaScript) on the server-side (years before node, potentially some Java emulator but we never found out) and output HTML with document.write() which didn't actually go to the browser then, no, it was cached and the response was saved as HTML and eventually shoved into page content after a bunch of MySQL queries had been run to find the cached output.

Slow? Yes. Confusing? Yes. Ridiculous? Absolutely.

To this day I maintain that if we DID have to shove a CMS in there, a copy of ExpressionEngine 2 and my Rest plugin would have done a better job and saved us about £499,600.

As soon as the project was complete - and management went off for their lobster celebrations - I threw down my crow-bar and quit. That is not the right way.

The Right Way

A Content Management System by definition just means that you should be able to manage your content. Outside of that a CMS should really not be interfering at all. If a CMS tries to make everything into one thing, be that "everything is a page", "everything is an asset", or whatever, then you are going to make it WAY too complicated for any mere mortal to ever effectively do anything.

As a developer you want to be given freedom to create custom URLs that aren't always a page, that can handle their own forms, their own HTML views, DB models that can talk to the database or some Mongo DB server somewhere in a far off land, or whatever the hell you like. If you want to build a module then your application should be given everything it requires to do that, and every module should be treated as a first class citizen of your application.

As a client you want to have access to well built add-ons that just make sense. You can't do that if you have to learn how to add everything as an asset or a channel or whatever, because it means that every single aspect of a website has been reduced and abstracted so far that it barely resembles anything logical. That goes for making everything into a Sitemap too. THAT DOES NOT WORK, so stop it, all of you.

A few more points for consideration:

  • Don't be a hero, use a framework - you instantly have a bigger community and greatly improved security.
  • Plan your add-on system well - Modularity is king. Every module should be a mini application with first-class access to everything.
  • Dont try and give EVERYTHING an interface - the internets will always at some point need a geek to poke some code, don't be scared of that.
  • On the contrary, don't force clients to code - complex "tag syntax" should absolutely be there for adding power, but learning it should never be required for an end user.


If you are building your own CMS then try and stick to some of these rules. There are enough systems out there and many of them are convoluted, confusing, restrictive and are giving my software a bad name.

PyroCMS will continue to develop along these lines and I will still use PyroCMS as a base for all sorts of random projects. People suggest you can only really build basic web sites, but I have recently used it for everything from massive boring corporate sites to iPhone backends and REST API driven websites that users can get a API Key for to do some cool things.

I generally see no need to "build it all from scratch" unless I am doing something really REALLY custom, for which I am always happy to have CodeIgniter and FuelPHP in my arsenal, but if I EVER have to write another blog or forgotten password system I will probably rage-quit the internet and become a kayak instructor.


Ben Corlett



I don't really have anything more to say than, this is the best thing I have read this week. Absolutely brilliant read, you have said everything I am thinking but you are better at conveying your ideas than I am.

Cheers big ears.

Donald Allen


PyroCMS truly is amazing. Used it on a spa website which should be up in May, and using it to build a law firm website. It's just so damn easy. I don't need to worry about finding a template library for CodeIgniter, or worry about making a polished backend, because one already exists.

Great work, Phil and everyone else who worked on PyroCMS.

Dave Smith


Hey Phil

Nice post with some very good points.

One thing. Wordpress is possibly a lot more robust than you think. It now offers internal APIs for building things the right way. It also is much more than just "posts".

I imagine your relationship to it must be something a kin to mine with Bootstrap. Bootstrap is awesome but i can imagine lots of poorly put together sites built by people who don't understand how to use CSS. Wordpress is similar but there are people out there who know how to use it the right way.

Perhaps I misunderstood your points. Do say if I did!



I just took a look at using wordpress for the first time. Frankly, its a cluster fuck of a piece of shit. The reason that it has done so well is that it caters mostly for users that have no programming experience, and the vast majority of users do nothing other than a stock install plus a theme change.

You can modify it if you want...but be prepared to sift through the spaghetti code.

Mei Gwilym


An interesting view of web history, plus lots to think about - great post.

I used Wordpress for years then wrote my own CMS on CodeIgniter when my abilities permitted. Hindsight tells me that neither is the best approach.

I recently did a small job on a WP site where the original developer had disappeared. 3 days after I finished, I was asked to take another look at it. I found that it was the victim of the base64(...) spam hack and all plugin files were infected. I won't be using WP on projects again.

I hope to use PyroCMS on a new project soon. Then any real custom work will on features unique to that site; and not building pages, blogs and other generic functionality.



"If a CMS tries to make everything into one thing, be that "everything is a page", "everything is an asset", or whatever, then you are going to make it WAY too complicated for any mere mortal to ever effectively do anything."

Not if that "thing" is low level enough. There is a point where all modules will need some common functionality. A good CMS would then allow resources to be injected into a module as necessary.

One problem with Expression Engine is that members are not a channel. If members are too different to have been wrapped in a channel, then there should have been a more low level base class or a DI strategy.

Aladin Bouzerd


One of the best reads I've ever had! Keep up the good work Phil.

Rob Allport


One of the best articles I've read in a while. Wordpress is a good platform, I just disgaree with developers who use it as a stareting point for every single project they work on.

Matthew Schenker


This is a great subject, Phil! It's something I know well, having spent three years developing sites with Joomla and WordPress, and some with Drupal. In recent months, I've been moving my development into CodeIgniter. Not all CMSs are created equal. ExpressionEngine and PyroCMS are from a very different world than Joomla, WordPress, and Drupal.

It all comes down to one word: “assumptions.”

Joomla (for example) makes many assumptions about your sites – how your pages are styled, what Javascript library you must use (it still insists on Mootools). Joomla assumes what your blog layouts will look like, what “read more...” text you will have in your blog intros, what your URLs must contain, what a “menu” is, what a “category” is, and on and on.

Perhaps most problematic of all – Joomla decides what fields will make up your pages (aka “articles”). This is what sparked my journey to other systems. I was getting clients who wanted unique fields for their pages, which means I needed to develop entry forms designed to gather unique data to display in customized layouts. This requires a powerful extension known as a “Content Construction Kit” (CCK). I've been using one CCK in Joomla (Seblod) that does a terrific job of allowing “custom fields.” Seblod essentially rescues Joomla from its own limitations and assumption, in my opinion. But what's happening is that Joomla loads all its assumptions for layout, design, and content, then the CCK overrides it all. Both the core assumptions and the overrides are running in every site built with the CMS.

About a year ago, I went looking at other CMSs to see which ones did not have such assumptions. I spent months testing Drupal, WordPress, ModX, then ExpressionEngine and PyroCMS. I would ask questions in user forums like, “How do you create custom fields in ... ?” I knew something was up when in certain forums the users did not quite know what I was talking about. It dawned on me that what I had become accustomed to calling “custom fields” in Joomla is business as usual in ExpressionEngine and PyroCMS. That got me looking at CodeIgniter and other frameworks, and the discovery of freedom has completely altered my approach to site development.

People point to the availability of extensions, plugins, and templates in a CMS. On the surface, this is good. But there can be major problems with interoperability. In Joomla, and also in Drupal and WordPress, each plugin occupies it own world, injecting its own set of design and function assumptions into your site. When you've installed several extensions, the assumptions of one compete and conflict with others. Diagnosing which extension is conflicting with which template can be time consuming and frustrating. It was wonderful when I realized that it doesn't have to be this way. With CodeIgniter (for example), libraries work with each other. What an amazing feeling when I realized I could use an auth library to set access to forms created with a form library! That would either not work or be next to impossible in Joomla.

It's true that many assumptions can be ironed out with overrides and custom coding. But that means you have to take the time to learn an esoteric platform. I've now become pretty well versed in the Joomla platform, but the same amount of time might be better spent learning solid PHP or a framework.

What Joomla and Drupal have going for them is initial development speed. If you're building a site that does not have too many custom requirements, you don't care about most of those assumptions, and Joomla and Drupal are often better. But when you need something unique, it's like a horse race: Joomla and Drupal burst out ahead at the starting gate, as other horses (PHP frameworks) start out behind. It's even by the middle of the race. By the end, frameworks and CMSs with fewer assumptions cross the finish line far ahead.

Peter Drinnan


I find that that typical decision makers don't understand technical rationales no matter how it is dumbed down. As a developer there is nothing more painful than being forced to use the wrong tools, which often happens because decision makers in reality often make complex technical decisions based on emotions. Microsoft knows this well. My point is that branding is more important than explaining to get the correcpt tools placed into the hands of developers.



Great post.

Pyro CMS delivers on so many levels, mostly simplicity.

Love this statement:

"If a CMS tries to make everything into one thing, be that "everything is a page", "everything is an asset", or whatever, then you are going to make it WAY too complicated for any mere mortal to ever effectively do anything"

The best system is one that gets used effectively.

Posting comments after three months has been disabled.