31 MARCH 2017
I have a feeling that if you’re here, you either strongly agree or disagree with the title of this article. That’s fine. This is an opinion piece, so feel free to feel however you’d like. But I have data to back me up! According to the 2017 Stack Overflow Developer Survey, 64.5% of respondents said they dread WordPress. It’s the 3rd most dreaded platforms of those they included in their survey.
I want to talk about why developers – the people who are knee-deep in the code; who could and would rather build a custom solution; those who are expected to make it work and work well – hate WordPress. This list is by no means exhaustive, but represents common pain-points I’ve found from my own personal experience and experiences others have shared with me.
Before getting into the pain-points, I feel I have to mention the things WordPress does well.
To start, it’s dead simple to install and setup. With a basic Apache/MySQL/PHP stack in place, you can be up and running in a matter of minutes.
WordPress is really easy to customize. The catalog of themes and plugins is massive and continues to grow. Building your own theme is really simple. Building a custom plugin isn’t as simple, but simple nonetheless.
And the main reason I think WordPress has become the go-to platform for so many people – the low barrier-to-entry for non-technical users. Once it’s up and running, just about anybody can manage and publish content with WordPress.
But WordPress falls short in a lot of ways. While this may come off as a rant, it’s meant as constructive criticism and I hope the WordPress team and community take it as such. These are the reasons why I, and other developers, hate WordPress.
WordPress started out as just a simple blogging platform – an easy way to publish content. But over the years, it has evolved into a chameleon of sorts. I’ve seen it used as a simple site management system, an ecommerce platform, a static site generator (yeah, I find this one really odd), a sales management system, a lead aggregator, a used-car inventory system, and a slough of other things.
One could argue this just illustrates just how flexible WordPress is – and I would agree – but when you try to do everything, it’s hard to do anything 100%. The vast array of available plugins is evidence of people trying to shoehorn WordPress into something they need.
At its core, WordPress caters to this plug-n-play approach. Don’t get me wrong, flexibility is good, but I feel like WordPress lost its focus a long time ago and without it, has been trying to find its way. Rather than focusing on being a great blogging platform, they’ve tried to be a great everything platform. A lofty goal, no doubt, that has unfortunately led to many shortcomings.
To their credit, WordPress still works really well as a basic blogging platform.
This is by far the number one complaint I’ve heard from developers. WordPress hacks are a daily, if not hourly, if not an every-minute occurrence. The common sentiment is that WordPress is swiss-cheese when it comes to security. That may be an exaggeration, but still, it’s a problem.
The problem largely stems from just how widely-used and well-known WordPress is and the fact that it’s open-source. Anybody can download and view the source code. This is definitely not meant as a slight on open-source projects. I’m a big open-source proponent and give props to WordPress for being open-source, but it makes finding vulnerabilities really easy.
According to w3techs.com, WordPress currently accounts for 27.7% of all sites on the internet. 27.7%!! I know the WordPress team works day and night to make sure things are secure, and they do a really good job. But due to the nature of rapid development cycles, things get through. And when they do, it puts a lot of potentially sensitive information at risk.
There’s no real simple, systemic solution to this problem other than to “keep WordPress up to date”, but WordPress’ rapid release cycle leads to other problems (more on that later).
There are those out there that will say “Do these simple things to secure your WordPress site…” They’re right. They are simple. But why should I have to do them? Why aren’t they just built into the core?
These are some of the things I’ve personally dealt with:
Just to name a few. You can’t expect an open-source project as large as WordPress to be completely impervious to attack, but that’s exactly my point. That’s a reason developers are so weary of it. They’d rather build something from scratch, specific to their needs, that they can lock down without the fear of new vulnerabilities being introduced with the next update.
“Hey, there’s a plugin for that!”
This is not the first thing a developer thinks when solving a problem. It goes against the typical developer mindset – architect a simple, elegant, custom-built solution. Turning to plugins for functionality requires a significant shift in thinking.
Ultimately, plugins do provide a way to quickly extend WordPress with specific functionality. One could definitely argue that WordPress’ plugin ecosystem is a strength, but it’s a double-edged sword. With the ease and speed plugins provide comes the potential for security vulnerabilities, version constraints, and bloat.
According to a recent report by wpscan.org, 52% of known WordPress vulnerabilities come from plugins. As a developer, you’re beholden to the coding practices, good or bad, of the plugin maintainer. If security is a cause for concern, which it should be for any developer, the process of introducing a new plugin requires vetting. If done thoroughly, this can negate the time-saving benefit plugins provide.
WordPress’ release cycle can at times be… aggressive. It’s not rare to see multiple patches and/or minor version bumps in a single month. This is completely expected as the WordPress team is constantly finding and mitigating attack planes in the WordPress core. But it’s incredibly frustrating how often these updates break plugins – ‘splosions everywhere.
It’s incredibly important to keep WordPress up to date, but this can come at the cost of a broken site due to plugin version constraints. There is an “upper echelon” of plugin maintainers that are constantly testing and updating their plugins against the latest WordPress release candidates, but the vast majority of plugins do not and when WordPress releases an update, cross your fingers it doesn’t bork your site.
I think I’m safe in assuming that the majority of developers like to keep projects lean and clean. While some plugins conform to this paradigm, so many are built to solve “all the things.” There’s usually one problem a developer needs solved and a plugin will solve it… and fifty other problems that aren’t problems.
Somewhat related to the issue of bloat is how obtrusive some plugins can be to the WordPress workflow. I’ve been forced to use plugins that completely change how posts are built and published. And I know I’m not the only one who has run into this.
A common complaint I’ve heard is that developers, and even site maintainers, end up working around plugins rather than with them. You’re probably asking, “Then why use that plugin?” Well, because it solves that one problem.
But enough about plugins…
WordPress is built with the assumption that a site will run on a single server with a single filesystem. More and more developers are moving towards a modern, micro-service, multi-node architecture because of the flexibility and scalability it provides. Getting WordPress to work in this type of architecture can be tricky for one reason – its deep reliance on FTP for updates.
Updating live code through FTP feels dirty and archaic these days. In an effort to find and resolve issues before code goes live, developers have adopted a workflow that typically involves local development, version controlled code, automated testing, and continuous integration. Uploading code directly into a running environment skirts all of this, leaving plenty of room for things to go wrong.
But a bigger issue is the assumption of a single-node/single-filesystem. Multi-node web clusters provide increased throughput and hardware failover. Hence the shift towards this approach. But if you install a plugin/theme or update WordPress through FTP, it can only apply the change to a single filesystem at a time. If you’re running on a multi-node web cluster, you have to run the update on each and every node separately.
Yes, there are ways around this, but it’s still a pain-point for developers. This also requires a writable filesystem in your live environment which I’ve already touched on as a significant security concern.
This is actually something I’ve dealt with recently. Starting out, the WordPress data structure seems pretty simple. But as you start to work with it, you start to see… quirks. For example, do you really need wp_posts and wp_postsmeta tables or wp_comments and wp_commentsmeta tables? Can’t meta information be included in the base table?
It might seem minor, but this structure makes it really easy to leave crufty, orphaned data all over the database. To mitigate this, WordPress has provided a collection of helper functions to aid in manipulating data. But when you have to manipulate thousands of rows, these functions simply don’t work. They run into PHP timeouts and memory issues and… they just don’t work.
Editing the data directly through SQL queries is easy enough and works great, but to avoid orphaned data everywhere, you have to completely understand the interconnected relationships between tables and write queries to match. This is true for any database, but so much of the data separation in WordPress’ database seems unnecessary.
I just want to be clear that WordPress is not a bad platform. It’s provides a simple-to-setup, easy-to-use solution for publishing content. But if you’ve come across a developer who’s been hesitant to use it, these are just a few reasons why.