Main content

WCMS - the Wordpress problem as we have experienced it

Den Howlett Profile picture for user gonzodaddy December 18, 2015
We are re-enigineering our Web CMS. Here's our experience with Wordpress and what happens next.

Shi(f)t happens!!

Barb Zinck's piece on whether you should build or buy a web content management system (WCMS) resonates very strongly with me. As the person who built upon a framework I know only too well the problems that are attached to working with Wordpress as both a platform and a CMS.

Right now we are in the middle of a soon to be revealed re-engineering exercise that will see us continue with Wordpress, at least for the time being. On this occasion, I want to walk readers through what we did, what we discovered and what happens next.

Early days

When we launched diginomica, we had no real idea how it would perform, what kind of audience would find it interesting (which is not the same as the desired demographic you use in planning) or what features would turn out to be critical. I had a number of years' experience with Wordpress but that was never going to cut it in the long haul when it comes to assessing diginomica.

We went with a mindset that recognized the importance of the mobile user as a first class citizens and attempted to keep everything as simple as possible. That worked until it didn't and we needed to add important features like the partner carousel. Most recently we've experimented with event content blocks. We've had fun and games with email sign up forms placement. Taxonomies are a perennial challenge. Along the way I've learned a great deal about where to concentrate resource and the limitations that Wordpress presents.

Limitations for the enterprise user

Here's a few things I've learned:

  • Wordpress does not natively scale without applying 'tin' to the problem. We went through several iterations with WP Engine before settling on a configuration that delivers the front end at good speed but which remains a dog at the back end. More on this in a bit.
  • There are very few real expert resources out there that fully understand enterprise needs. You can find thousands of sites dedicated to Wordpress, many of which are very good. Most are aimed at the small, brochureware sites - which by the way run perfectly well on Wordpress - or the hobbyist blogger. Back in the day, Wordpress was a relatively simple set of PHP files. Now it is a sprawl requiring 'proper' programming expertise to make it sing. That's why I am now banned from writing code!
  • Forget what is said about open source standards and especially as it applies to plugins. Wordpress offers little by way of standards enforcement which, in turn means that contrary to the advice given by Neville Hobson, you will have no idea which plugins are causing problems when things go wrong except via a brute force analysis or the use of sophisticated analysis tools. As an aside, much of what Hobson says is 'ok' but on testing he is flat out wrong. There is no plugin testing in the conventional sense in the world of Wordpress. This is one of its fundamental weaknesses.
  • Wordpress was never conceived as a CMS. It has evolved into that world but it doesn't natively support many of the enterprise class requirements that a modern WCMS demands. The translates into engineering chores where professionals are an absolute necessity.
  • Dedicated hosting is great and even better when it comes with a sandbox of the kind WP Engine offers. But there are trade offs. Anything performance related is under the hoster's control and that will cramp your ability to both fine tune and extend Wordpress as a platform.
  • Not every support professional is made equal. Some are downright appalling. Others are hobbyists who found a niche they can manage. Still others actually know what they're doing - most of the time. But not always. The real experts are very thin on the ground and relatively expensive. A good support engineer is worth their coin so expect to scope and pay accordingly. As a hint, someone who is a programmer at heart, knows Java, javascript, PHP, HTML and CSS as basic language proficiencies will 'get' Wordpress and its limitations. Increasingly, you will need folk who understand javascript variants like angular and who can work proficiently with technologies like Solr.
  • Wordpress is built on what is now an aging platform and language set. You can't for example migrate to NoSQL Couch or Mongo as databases because Wordpress is built on an apps and database metaphor that inextricably links PHP to MySQL. You can overcome a number of the limitations that come with the Wordpress architecture but in its current form I don't see a long term future for Wordpress as a scalable WCMS platform from which I might build an entire digital presence.

The killer UX that keeps us here

Having said all that, then why am I sticking with Wordpress?

It's dead simple for users to pick up and run. This is one thing that sets Wordpress head and shoulders above every CMS I've reviewed. It requires virtually no training beyond instruction around custom fields, the use of taxonomies and media library management. You can get a similar look and feel elsewhere but it is an interface programming job. Anyone who has done that work knows just how hard it is to get right. Wordpress recently hinted at moving in the direction of node.js with Calypso as a front end editor. Having taken a quick peek, I like what I see. But, Calypso is a v1.0 with many, many issues and the core Wordpress code isn't going away from PHP/MySQL anytime soon.

In short, the user experience that has helped Wordpress become the de facto website construction tool of choice for a quarter of the sites out there has been the killer feature. Plugins matter for sure but as in any IT project, you must have the editorial user experience top of mind for a WCMS.

We conducted a lengthy search exercise, considering alternatives to Wordpress, and even mulling one of Zinck's correspondent's recommendations; rolling our own. There is definitely a case to be made for the latter route but we had to decide whether becoming a media AND software business was in our best interests for the foreseeable future. The answer was 'no' - but only just.

Selecting an alternative WCMS proved too difficult. I can tell you flat out that while there are many, many WCMS choices out there, it is the Wild West. Cowboy operators abound, snake oil salesmen are on every corner and nothing out there will be usable without adding in a shitload of development resource. In one case, what is a $30K pa operating budget rapidly turned into a $400K deal with 560 man days of dev including 70 days UAT on the first cut of the Gantt chart. Now - if you've got a spare half million bucks then fine, knock yourself out with whatever you decide. It just wasn't for us and in retrospect that was a good thing.

We learned a great deal about what I see as the arcane world of enterprise software negotiation as it applies to WCMS vendors. Everything is up for grabs and providers hope they don't leave a dime on the table and you hope you don't forget something critical in the bill of goods.

We may well come back into the market in 2-3 years' time but when we do, it will be with the benefit of having lived with the kind of compromise that is important at this stage of our young life.

What next?

As I said earlier, we are sticking with Wordpress but we are re-engineering it, pretty much from the base core up. We are dumping as many plugins as possible and turning required functionality into the core. This will allow us to ensure that every major piece of functionality is battle tested against a common code line. It means we will have control over the code in ways that are otherwise not easy to parse, even in the open source world.

We are looking at every function, every piece you see on the page and questioning its value to readers and to us. This means we're actively stripping functions that may be nice to have but do not add value.

We will only use plugins where the code effort is out of proportion to the value we can achieve from building into the core. But, those plugins must come with premium support for which we will pay.

One of the biggest changes will come in the hosting decision. We've not got this nailed but right now, I'm leaning towards Amazon Web Services. They are the big dog in the room, they continually innovate and they provide us with a way of ensuring globally consistent performance. We need to scope the cost/benefit analysis carefully before making that final decision.

All of this is a far cry from what we launched in the spring of 2013, and while we've made our fair share of mistakes, we think the plan going forward is not only viable but sustainable and capable of significant growth both out and up.

Final thoughts

There are considerable risks in what we are attempting but we are going into this with eyes wide open. We are in the fortunate position of not having to make a jump at this time so if it all goes pear shaped on Day 1, then we have a fall back position that preserves everything we do today.

Some will argue that we are almost going a form of closed source and there is a degree of truth in that. But, we have chosen a partner, not a dev shop, who will walk hand in hand with us along this journey. Just as in the big bad word of enterprise software that runs your business transactions, we need a real partner who will be with us as we continue to evolve and iterate what we do and who understands the business plans we have in mind. For us, is  the business so this is not just business critical, it is a non-negotiable requirement.

In the meantime, I am stoked at what I am seeing and the progress we've made. I like what we will be offering in the coming year as fresh and different functionality that will, I think, please everyone. I like that the back end performance, which has been a royal PITA for over a year, is running wicked fast. I like that we will be making editors' lives easier because we can then properly accelerate content production, curation and promotion.

Featured image credit: Signpost concept © pablographix -

A grey colored placeholder image