WordPress: an enterprise-grade CMS?

This is the first in a series of posts on how AgencyUK will be developing a new Core theme and suite of plugins to use on our projects. This first post is an overview on why we use WordPress, and a discussion on the need to enhance the platform in order for it to stand shoulder to shoulder with other content management systems.

TL;DR

WordPress needs work to be a fully-fledged CMS and AgencyUK are going to document how we’re dealing with the challenges of leveraging WP as an enterprise-grade solution.

WordPress then and now

Much has been written on how the pre-eminent blogging platform of our time has morphed, almost reluctantly, into a content management system used by over 3 million websites. Now with 64% of the CMS market [source], it’s hard now to reconcile that coy initial 0.70 release with the thorough bug fixing and security updates now bundled with every new version; undeniably, the framework has matured considerably since 2003.

Clean, Lean, and Mean

That heading ^ appears in the “About” section of WordPress.org  [link], and I’d like to quote one paragraph in particular:

The core of WordPress will always provide a solid array of basic features. It’s designed to be lean and fast and will always stay that way. We are constantly asked “when will X feature be built” or “why isn’t X plugin integrated into the core”. The rule of thumb is that the core should provide features that 80% or more of end users will actually appreciate and use. If the next version of WordPress comes with a feature that the majority of users immediately want to turn off, or think they’ll never use, then we’ve blown it. If we stick to the 80% principle then this should never happen.

I highlight this because here at AgencyUK, we roll WordPress for a considerable number of clients of varying sizes, needs, capabilities and budgets. The reasons behind our choice are completely obvious:

– easy learning curve for end users
– massive, knowledgeable and friendly developer community
– it’s free

Crucially, these are benefits that we can pass directly onto our clients.

However…

Every time we roll a WordPress installation, the fabled “5 minute install” has become something of a running joke; don’t get us wrong, getting WP up and running locally for us actually takes something like 20 seconds but getting WP into a state that we would call “fit for purpose” takes considerably longer.

To elaborate a bit; setting up WP doesn’t take any time at all, and that’s what the 5 minute install promise is referring to. The trouble us, to get it do anything approximating what we consider a modern CMS should do takes rather longer.

– Granular, page specific permissions for specific users
– Page caching
– Social media integration
– Form building…

That’s four things WP doesn’t do out of the box. I’m going to go out on a limb here and say that if WP wants to call itself a CMS capable of squaring off against Drupal et. al, then this kind of stuff should be bundled as standard. Again, from the “About” page:

It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

I wholeheartedly agree. But on the other hand, I find myself installing the exact same plugins with each install, every – single – time. There are some who’d argue that this flexibility is precisely the point of WP, and that not all the features I need will be needed by the next person – and I would in turn admit they have a point.

Let’s come back to that ‘Clean, Lean and Mean’ quote:

the core should provide features that 80% or more of end users will actually appreciate and use

I’d suggest that our four conspicuously missing features would indeed be appreciated by 80% or more of end users.

So where do we go from here?

Fork it?

There has been much debate on forking WordPress, and it’s a debate I find myself re-reading every few weeks or so. Morten Rand-Hendriksen kick-started the debate here: http://mor10.com/wordpress-at-10-time-for-a-fork/, and I highly recommend reading this and the other commentary linked at the foot of the article.

I see WordPress stripped down to a core application with a series of prongs, each targeted towards a distinct user group or scenario. This can be done either through distinct forks or through plugins much like BuddyPress and e-commerce are being handled right now…

One of the more compelling rebuttals of Morten’s viewpoint came from John Saddington:

…to fork it, and even stripping it out to the “core” Core and then building modularly would, practically speaking from an engineering perspective, be akin to adding a fifth wheel to a car or, as a friend suggested, making the steering wheel square. It just doesn’t make sense from a pragmatic point of view, and this isn’t even talking about dependencies, like server configurations and the like. Forking could jeopardize those staples overnight.

(From http://torquemag.io/never-fork/)

Having a core WordPress release feeding into forked versions more suitable to their purposes is a tempting notion; but as a development community, do we want to take the risks of fragmentation as the price of a more tailored WP package? Maybe having a solid core release that we can rely on should win out over demands for extra features… at least for now.

Rolling your own

We return though, to a pressing short-term need, away from long-term considerations of the platform as a whole. If we have to roll our own combo of theme hacks and plugins, what can we do to make the process easier?

Fortunately, help is at hand with tools like http://wproller.com/, which creates nice bundled zip files with all your favourite plugins ready to roll. Is this problem solved? Perhaps. In future posts we’re going to look specifically at what options there are for automating WP deployment.

The future

AgencyUK have decided to maintain a suite of version-controlled core plugins, plus a core theme which will meet most of our needs in the short term. The theme and the plugins will look to jointly address some of the issues inherent in WP and bring the framework up to what we would consider deployable and client-ready.

The Git repository containing the “Agency Core” can be cloned or forked and used to scaffold new projects; this alone will save us a great deal of time and energy in getting projects moving forward – again, benefits that we can pass straight on to our clients. This approach is not a new one, but we think that the lessons we’ve learnt and will learn in the future by taking this approach are worth documenting and sharing via these posts.

The next post in this mini-series will focus on the specifics of getting the core theme up and running, discuss some of the challenges we’ve encountered, and offer guidance on how small teams can use the core offerings as part of a Git-flow based methodology.

As always, send us your thoughts @gency.