WordPress sucks! (right?)
By: Travis Weston
Tags: Wordpress Development, Code Quality, Web Development, Codelife, WordPress

I get it. WordPress is a big target, and everyone else is doing it, so that must mean it’s fine to pick on it, right?

Wrong.

We have a zero tolerance policy around bullying here, and I intend to enforce it. Not only is it rude to the millions of developers and users out there who live their lives off of WordPress, but frankly, you’re just wrong.

Photo by Jerry Zhang on Unsplash

I’m going to start with the most important point that I’m going to make through this entire article. This concept permeates everything in this article, and everything that I think about WordPress.

Only a bad developer blames his tools

WordPress isn’t bad. WordPress is a tool. You can’t blame the tool because you don’t know how to use it properly.

We are developers. As developers it is our job to make sure our systems are designed the best way that they can be. Our focus is on security. On extensibility. On growth potential, and performance.

WordPress is a content management system. The only thing WordPress cares about is making it easy for someone to go from no blog, to having a blog. And for that, it works wonderfully.

WordPress is a dull blade that must be honed

Instead of complaining that WordPress is what it says it is, we should go into our interactions with it with eyes wide open.

For most people, WordPress is perfectly fine for what they need. For others, like you and I, it is a dull blade that we must hone to the sharpest of edges.

How do we do that? By taking stock of what functionality we are provided by core. When we break it down, we are left with three things that will speed up most site-wide projects: User management and authentication, content management, and a hook system that allows us to modify damn near any core function that we need to.

How long does that take to do? Any guesses?

In my time as a web developer, I have chanced to build each of those three features on their own. I can tell you this: To do those, you will be investing at minimum a month of your full time efforts. To do them well, you’re more likely looking at 6 months.

How much is 6 months of your time worth?

“But, plugins are terrible! Too much reliance on someone else’s code!”

You’re kidding, right?

Oh, you’re not? Okay, that’s fine, so you’ve never used a framework? Or composer? Or Node package manager? And I’m sure you’ve never installed anything from PECL.

We all use other people’s code every single day. Hell, just to get a website on line you’re using someone else’s code in your operating system, your web server, and PHP core itself.

Let me try to get at what I think you’re really saying when you say the above: “Bad plugins are bad, and bad plugins are more prevalent than good plugins.”

I think that is both fair to say, and true.

The thing is: Bad code happens.

If you are concerned about bad plugins, fix it. Install the plugins that you need, find the ones that you need but that are subjectively “bad”, and write your own version of those.

And then release them onto the plugin repository.

If more good developers write good plugins, non-developers will have more to choose from.

But I don’t like writing plugins because Globals

I’m going to be real with you here: I have been writing WordPress code professionally for the last 6 years. I’ve been writing WordPress code in general for the last 12 years.

I can count on one hand the number of plugins I’ve written were forced to directly access a global.

Using proper clean architecture, and encapsulation techniques, you can write the core functionality of your plugin without even needing to be in a WordPress installation.

Photo by Iza Gawrych on Unsplash

Like a Matryoshka doll, our code should be nested inside of itself, hiding the core functionality from WordPress, and hiding WordPress from our code. This allows us to do a few things.

First, we can update our code without concern for which version of WordPress will be running it. Second, we can update the WordPress specific code without worrying about breaking our core functionality code.

Third, and least important for this article, we can pull our own code out and reuse that API to build non-WordPress plugins. More on that in a my article about Polymorphic Plugins.

Fine, fine, but what about the fact that you can’t run it on multiple servers because of the FTP updates?

This one makes me laugh because it’s so patently false that you can tell people who use it as an argument were just trying to fill up space.

First of all, how many of you update your core website in production?

Anyone?

Bueller?

I didn’t think so. We don’t update our core website code in production because that’s just a recipe for disaster, no matter what system you’re using.

If you are a professional developer, and you are running any website in production, you are disabling all sorts of things. For instance, on WordPress, you’re disabling updates and direct access to code editing.

define( 'AUTOMATIC_UPDATER_DISABLED', true );

define( 'DISALLOW_FILE_EDIT', true );

With those two lines, you stop your end users from being able to mess with the code running your WordPress site. From there, you will implement a continuous integration process, which is beyond the scope of this article.

All of that said, all of this really boils down to…

Good WordPress code is just Good Code

This is a topic I’ve been harping on for a while now.

I won’t go into detail about what I think good code is. You can read the linked articles for that. What I will say is that WordPress doesn’t preclude good code. Say what you will about WordPress core’s code quality, that shouldn’t matter to you as a developer.

What matters is how your code interacts with their API.

And I don’t mean the WordPress REST API. I mean the public API that they provide for expanding and customizing WordPress core. The action hooks and filter hooks.

How you interact with the core WordPress API determines how good WordPress is to you.

Millions of sites use it daily, including some of the largest newspapers in the world.

So if you’re still running into issues, WordPress has one thing left to say to you:

It’s not me. It’s you.