WordPress

When is WordPress NOT the answer?

April 19, 2014 • Ben May • , , ,

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.

wordpress-app-platform

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:

wp-locked

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?

Conclusion

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.

More articles