Why WordPress is the [false] King of CMS

Let’s first start by answering questions that people have started writing in our comments for our Joomla related blog and tutorials. Many folks have asked us why we’ve started using WordPress(WP) so much more than Joomla when we’re supposed to be “Joomla People”. I have many answers to this question.

(or why we started using WordPress more)

(or alternatively the reality of website design and development agencies)

Let’s first start by answering questions that people have started writing in our comments for our Joomla related blog and tutorials. Many folks have asked us why we’ve started using WordPress(WP) so much more than Joomla when we’re supposed to be “Joomla People”.  I have many answers to this question.

Basically, it comes down to client needs. If the client wants and can only pay for the time spent on a WP site, that’s what they’ll get. Code quality and scalability via code is not a concern for most clients.  Clients want easy, simple, and fast.


Why WordPress is Awesome (for our website clients)

WordPress is awesome in so many ways for our clients. Let me list you the reasons:

  • Client recognition of the CMS (aka Branding and trust for the platform)
  • Great Documentation
  • Great Community Support
  • Easy to use backend UI
  • Out of the Box SEO friendly URLs
  • Complete backwards compatibility to version 1 (So clients do not have to worry about base system changes from version 1.5 to 2.5 like they would on Joomla)
  • Customizable post types integrated into the main menu for when the client changes their mind
  • ACF (Advanced Custom Fields) and its “Repeater Field” plugin which allows us to place in content in any way we want when the client changes their mind to make another slider
  • Infinite plugins for when the client changes their mind and wants to add an unexpected functionality
  • That other time, when that client changes their mind, we’ve not invested in complex MVC backend code so we can change it quickly too.

Basically what I’m telling you is that WordPress is great at people work. Its got a lot of what we humans call “Soft Skills”. Very flexible, listens to you well, isn’t hard set on an idea, etc. That said, its foundations are less than fantastic; not really object oriented, and not really frameworked.


WordPress is flexible and great for the users.


Let’s talk about Procedural vs Object Oriented Programming

(or Why WordPress is not going forward with PHP)

Because PHP as a language has moved so far along as of recent (especially 5.3/5.4), it has changed the way we can program in the language. Class autoloading, lambda functions/closures, namespacing, etc. The list goes on. To take advantage of most of these functionalities, the codebase itself has to be objected oriented and most likely in a framework setting. While the underlying language improves, WP won’t be able to take advantage of many of these things. The plugins that are in WP will probably could make use of all these things, but for the core, it is unlikely. That said, there were no real major PHP MVC or similar framework types in 2003 when WP started. This also has to do with the language limitations at the time within PHP 4.


WordPress is not object oriented at its core. This limits its ability to grow beyond a certain point with PHP. As to its audience, it may not need to grow to scale at all; we’ll cover that idea later.


How WordPress Evolved for the Client

We’ve covered our workflow and how we try to help clients figure out their goals and priorities before starting a project. Even with our well thought out workflow, clients often change their mind mid-way and cause a huge barrage of design and engineering nightmares (and don’t forget the budget nightmares). We know this happens because we’ve seen it happen for the smartest of our clients.

If our earlier list is any sort of an indicator, we love WP for its flexibility in these client nightmare scenarios. I have to be honest in saying that WordPress’s absolute flexibility let’s our client get away with almost anything.

That said, this flexibility can introduce a lot of problems for coders who have no structure. Its greatness can only be captured by the people who have a good structure to begin with. I’ll be honest in saying that it took us time to properly make websites in the start too. Like great artists who create abstract art you have to be equally talented and capable in the classic arts (or in this case object orientation and general code organization). I must say it feels weird breaking rules all the time (Global variables like $post, spaghetti code, etc)

WordPress and its ecosystem developed to handle the kind of flexibility that clients require. 

WordPress has gone through a series of tough childhood challenges; a series of unfortunate circumstances rolled into a package in a whirlwind of events. That said, its a flexible and mature product that fits the bill for many clients.

WordPress evolved to mold to the needs of its user base, both developers and end users. The evolution was for maximum flexibility over forward thinking code (not necessarily bad code). Flexibility was required since most client and agencies do not have a great workflow.


Client perception and the reality of most websites

(or why WordPress might just be right for most clients)

I hate to say this, but many clients perceive websites as something of an instant ramen. Quick, easy, and disposable; something that should happen without thought. Obviously, we don’t think that should be the case. Quality takes effort.

This isn’t to say that developers should have to compromise their code, but to consider the needs of the client. What do most small to mid size clients want when they’re building a website?

  1. Page View to Customer Conversion (usually this means good design and measurable results)
  2. Within their budget (inexpensive)
  3. Within their timeline

The above three client concerns usually have almost nothing to do with the code quality of the site and therefore the lack of framework within the CMS is often not an issue; this is especially true for informational websites which can be cached for performance.


We don’t want to settle on WordPress

We’re not exactly happy deploying code that we don’t believe in 100%. That is why we started our search for technology that fulfils both client needs and our wish to write/deploy better code for websites. Unfortunately, as with any piece of technology research is required to make the right choice.

Here are a couple of options beyond WordPress that we’re definitely considering for CMS/blog packages:

We can’t go into the details right now for each of the above systems; we’ll save that for another post. In any case, we hope that the CMS world moves beyond WordPress soon.


In Conclusion

The final lesson here is that perfect is the enemy of good. That said, we’re not ones to settle for less.

We’re looking to see how all of those systems including WordPress grows as the web changes from a static place to a more dynamic place. I’m hoping that with the underlying structures getting better, we’ll be able to deliver more dynamic websites at lower engineering costs in the near future (I’m really liking what October is doing with is Asynchronous Stuff!).

I know that this post may seem directly opoosite in the message to the post we wrote earlier; the reality is that we found this tool (WP) to be far better for the client though not neccessarily for us.  In the end, we have to keep our heads clear and decide technology based on the client’s needs.


Continuing the Conversation….

Do you have a new favorite Open Source CMS that we didn’t list (also not limited to PHP)? Let us know in the comments. 

PS: We don’t like Drupal (overly complex and becoming something very different at version 8) or care for ExpressionEngine (PyroCMS anyone?).  (We can explain this in another post, but we’re just putting it out there.)