When is WordPress NOT the answer?

As of late, we’ve had a couple of large web application projects where the deliverables did not include any CMS functionality. That is, they were purely a functionality based web application.

I’ve been reflecting on both of these projects, and how we approached each one for a couple of reasons.

Firstly, did we make the right choice with the underlying framework?

Secondly, further to the first point, could we have done it faster/better/smarter if we did it another way.

Thirdly, what is our business, should we be building non WordPress projects, and if we do non WordPress, do we end up doing 100 different frameworks so-so, rather than doing one really well?

I’m going to write about one of these projects in the future, so I won’t go into too much about the projects – just the approaches and thought processes. I also won’t go into the other frameworks too much here, I’m more interested in exploring how you base your decision purely from WordPress’ offerings. So you know, the other frameworks we use are CodeIgniter and Laravel.

When is WordPress the right framework?

Well first of all, WordPress has a bit of an identity crisis going on. The argument that WordPress is a framework has been around for a while now and I believe it’s where WordPress will be – just not anytime soon, though slowly it inches towards it. Jake Goldman wrote a little while ago, a very detailed piece and generated a very good discussion about “Is WordPress an App Platform”.

For a while, and as I write this, I believe WordPress is more than a blogging platform, and more than a CMS, I think it’s a “Content Framework”.

What’s WordPress good at?

WordPress offers a bunch of flexible constructs that allow you to store, group, link, and work with content until your heart’s content.  Being able to rapidly create data sets with taxonomies in the backend of WordPress, with tools like Advanced Custom Fields to allow administrators to modify data in an incredibly short amount of time is a real plus for WordPress.

Not many software packages can let you do this so rapidly. This is one of the things I’ve loved with WordPress from day one. Being able to rapidly get the “grunt work” (boring, repetitive tasks like building admin layouts) out of the way so quickly, and getting to work on the customised functionality of the project.

Advanced Custom Fields has made this process even faster, being able to build custom admin UI for managing data, and having things like photo uploads or repeaters running so effortlessly is again, a major win.

What’s WordPress bad at?

One of the common complaints from both WordPress and Non-WordPress developers, is how tightly connected certain things are. Instead of starting with a blank canvas and building up, you get something half built, and if you don’t want it, you need to actively remove it. Removing things in WordPress or WordPress admin can also be disheartening when you end up using CSS and jQuery hacks to hide elements. It feels like an amateurish and hacky solution, because it is.

At WordCamp San Fransisco last year, Matt Mullenweg spoke to the WordPress as a Framework push, and showed the following slide.


What the above says (to me) is that WordPress is a bunch of low-level functions and code, that you then plugin in on top of that a CMS, and if you want, a blog, or ecommerce, etc. Meaning you can pick and choose the bits that you need for a certain project. The majority of users picking three or four of the above ‘blocks’.

However, as of today, these building blocks are so closely tied together, and “WordPress” aka the standard WordPress software package comes like this:


So what’s WordPress bad at? It’s bad at only being a framework. It’s bad at just being a CMS. It’s bad at just doing one thing and building on top of.

In the project I mentioned above, that we did in WordPress, there was a lot of horrible code that was required to do what we wanted to do.

Don’t want this here? Oh just use CSS to hide it.

Don’t want that shown? Just use this line of jQuery to hide it because there is no css to identify it.

Want that link hidden? Use a filter to intercept the array and yank the item out by doing a string match.

All of these kind of approaches make me feel as if I’ve failed as a developer, and that I’m just as bad as the newbie developer googling for snippets on Stack Overflow to build something. The disappointing part is that these hacky approaches are often the only approach with edge cases in WordPress application development.

How do you choose?

This is the hard part. What horse do you bet on?

Do you go with WordPress because it’ll deliver a massive head start on the project and get you up and moving with real data quickly. You’ll be able to have editors / admins / clients inside the admin area very quickly and working away. Sure there’ll be a couple of hacks to get the admin UI going but such is life.

Do you go with a more traditional framework, like Laravel, Symphony, CodeIgniter, and so on. Do you spend a bit of extra time building your CRUD interfaces (Create, Read, Update, Delete) but make up the time with greater flexibility because you’re now using your own data constructs and methodologies?

Here is how I go about it, these are the questions we as a team chat through to work it out.

Can we use ACF and WordPress to save us a considerable amount of time in grunt work?

Looking forward, and if we use WordPress and ACF for data storage, what might not work? Can we query data backwards efficiently for example.

Are we going to have to undo more of the WordPress admin than we’ll actually use?

Are we going to write our own URL routing for all the UI, skipping WordPress admin & front-end theme altogether? (This is a pretty significant one).

Who are you?

Thinking through this post, it’s the logical question to ask of someone:

Are you a web development company that specialises in WordPress development, or are you a specialist WordPress development company?

If you’re the later, then you really should pass up projects that don’t suit WordPress.

If you’re the former, then I worry that the risk is you end up having to support a big list of software packages built on different frameworks, which is a cost your business has to absorb and try pass on to the customer.

For me, I’ve always loved CodeIgniter, and recently had one of the team complete a project in Laravel, which I’ve done some work on, and have really enjoyed it, and interested in another project or two in the same framework. Laravel, from my understanding, is basically where all the CodeIgniter people live, because it’s so much better.

I don’t think there is an answer to this, so let’s leave it as a rhetorical question, eh?


This is tough subject to discuss, without sounding like you’re doing a bit of WordPress bashing, which a lot of people love to partake in.

The fact is, 90% of my businesses “development” revenue is WordPress. Other frameworks, or legacy systems etc are a very minor part.

A mantra of mine is, the best tool for the job. That is really what it comes down to. I don’t want to build an application in WordPress just because we are good at it, and it’s technically possible. The best platform should be evaluated without bias and moving forward.

I also don’t want this post to sound as if I’m partaking in said WordPress bashing. There are a heap of good reasons why WordPress isn’t a framework like Laravel or Symphony. The WordPress leads do a good job of trying to strike a balance, and in the last four years or so, WordPress has taken leaps and bounds in this very field.

Ben May

I run a small WordPress development agency, specialising in enterprise and high end WordPress engineering challenges. I love good coffee, fine food and wine, and working on the web.

12 thoughts on “When is WordPress NOT the answer?

  1. Thanks for sharing Ben. I’m working on a web project that’s currently being built on Laravel and I’ve found that building a blog/CMS component into the application was easier than extending WordPress. The freedom of creating exactly what you want, where you want it is very nice indeed.

    1. Yeah, that’s always a really tough one when you want to built an app w/ a Blog etc. I’ve been caught in that position, where you end up trying to build an entire CMS into an app, which is stupid.

      Best mix I’ve found is to have for example, app.domain.com for business and domain.com for CMS/Blog etc, and use API’s to share users etc.

      Last thing you want to do is be spending so much time doing CMS/Blog stuff when it exists!

  2. I find WordPress particularly useful as a proto-typing and Minimal Viable Product development tool. You can get something that works up and running quickly, and either hide the rough edges with CSS+JQuery (been there, bought the t-shirt), or even let them hang out – because it’s a quick and dirty prototype, right?

    When it becomes time to build a real system capable of supporting a large number of concurrent users and that doesn’t feel like the software equivalent of an elastic band and 3 rolls of duct tape, that’s when it’s time to refactor it as a CodeIgnitor/CakePHP/$insertFrameWorkHere system. But there’s no point in investing effort in a framework based system at the start of the project unless you’re very confident it will be a success.

  3. Thanks for the article, Ben! Although I started out in the “real world” of web development, most of the stuff I do now is built on Genesis or Thesis–because that’s what my clients want/need. Sometimes I fondly remember the good ole days but then I also remember the stress it caused when I spent so much time developing something only to have the client change their mind–even with a good requirements document. Sure, it meant more money but it also seemed a waste of my original time.

  4. Using Advanced Custom fields is the wrong way to extend WordPress. It just doing the job on the simplest way, and you can’t much plan the database with it. So you can use it on small-sized websites.

    There are better plugins for this, for example PODS framework – making WordPress, Drupal like CMS.

    I agree with you that WordPress isn’t just for everything… However, for example I am not a fan of Magento, and I am still using WP+Woo for small to medium sized e-commerce websites. For some more complex e-commerce I would probably end up using some php framework instead of Magento.

  5. I’ve faced a few of these issues with WordPress (dropped it for Drupal) before and I think a lot of it stems from WordPress trying to break out of it’s blogging roots and trying to be more than what it actually is. WordPress is a fantastic blogging platform but beyond that I feel it lacks the tools to really do more.

    If you want a framework based on WordPress maybe it’s worth forking it and building in an api model designed for being developed on as a framework.

    That being said if full CMS capability isn’t needed it might be worth picking up rails/node/django and learning to develop in an app framework.

  6. hi ben, it was a great article..i want some advice from you, i want to build an web app like uship.com …which platform should i need to use?? Laravel or wordpress?? i have built lots of websites on wordpress being a wordpress freelancer….Kindly reply me…Thanks

  7. You had me when you talked about the hacky approaches. Building anything substantial in WordPress always gets me thinking what the hell I am doing.

    On the surface it sounds pretty easy, that if you need to do X use Y plugin or use the Z plugin its so much better. But when the requirements change from X to W, now the plugins Y or Z may not be a good fit, so you keep thinking and then you start hacking plugins and themes.

    One big reason I think people stick to WordPress is the beautiful back end interface and the flexibility with which you can customize it. Its just amazing. Many free and paid CMSs/frameworks still can’t match that. But the fact remains WordPress is not written as an application framework, so it becomes difficult, tedious, and boring when you app starts growing on you.

    I think app frameworks need to learn something from WordPress instead of WordPress learning from them!

Leave a Reply

Your email address will not be published. Required fields are marked *