WordPress Sucks!

WordPress Sucks, get your attention? Didn’t I, you might think that’s a little provocative, but as much as I love WordPress, and I’m sure you do too. There’s plenty of things that do actually suck about WordPress. This isn’t going to be some sarcastic talk it’s time that we actually take off our Rose colored glasses and take a look at some of the things that make WordPress suck.

But first, who am I? And what rights do I have to say that WordPress sucks. Uh, my name’s Cameron Jones. I’m a WordPress developer from Victor Harbor in Australia, and I’ve been building WordPress sites since 2014. And I also run the plugin store mongoose marketplace, uh, before we start, I’d just like to say that I may cover some touchy subjects and all opinions are purely my own.

Now let’s dive in.

We’ll start off by looking at the database structure. When WordPress was first developed, it was purely a blogging platform. And as such only had posts as it’s grown to include pages and custom post types, these new types of content have just been extensions of a post at its core, a page is a post a product is a post an order as a post.

And they’re all stored in the same post stable. There are two main issues that this has the first issue is that it makes it really hard to merge content between multiple environments. It’s not so bad for mostly static sites. But for very active sites like e-commerce stores and forums, this can become a nightmare.

If you make a new post on a staging environment, for example, it will be given an ID, but in a production environment, the posts with the same ID, it could be something completely different, like an order image or even a revision. The team at Delicious Brains tried to build a solution for this called merge bot, but they ended up abandoning the project.

If they can’t figure out a solution for the issue of conflicting ideas, it’s probably not possible in the current state of the database structure. The other issue is that with all the post types sharing the post table, there’s no opportunity to customize the columns of the table for the different data each post type needs.

So all goes in the post meta table in some ways. The way that post metal works is great because it’s flexible and particularly easy to store repeating content. However, because each item of post metal takes up a row in the table, it can get very bloated very quickly. It also means that you can’t set up query indexing on a specific column, which would make for faster queries.

Combined, that means that WordPress post queries are usually going to be slower than it should be for a simple static site. This wouldn’t be noticeable, but on sites that scale, it can be quite inhibitive. The database is fairly rigid as a lot of the way WordPress works, relies on it being set up the way it is, but there are a few things you can do to help mitigate these problems.

If you have control over the types of content being set up so that you’re registering your own custom post types, you could use pods, custom content types, which sets up its own tables for each of the content types. But that won’t work for something like WooCommerce that comes built in with their own custom post types.

If you have control over the post meta fields that are being used, you can store them all as a single serialized array, meaning that there will only be a single row of post metas stored for each post in the database. This does make it harder to query posts by a specific meta field though. And again, if you’re relying on plugins that have their own custom post types, there’s nothing you can really do with those in an ideal world, registering a type would register a new table specifically for that post type.

And you have an opportunity to add custom columns for posts meta when you registered that post type, but that would require a lot of breaking changes in core, unfortunately.

As we’ve already kind of covered a custom type of content, such as a product, shouldn’t really be an extension of a post. There are both some columns in the post table and properties in the WP post object that you probably don’t need, like fields for comments and ping backs. On top of that, there were likely also other properties that you want stored for every post in your custom post type that you’ll have to store as post meta, which can be less than ideal.

Additionally, there are some aspects that posts have the other post types can’t for instance, custom post types can’t have sticky posts. It is possible to recreate the sticky posts functionality by using a Postmate field and filtering the query. But. And there appears to be some plugins that can fix this.

However, it is just one of the inconsistencies between posts and custom post types posts can have the archive as the homepage or assigned to a published page, but custom post types have no such options. They can only have a dynamically generated archive or none at all. It means that without code you can’t change the permalink for a custom post type archive or set it as the homepage.

It can be quite frustrating trying to put together a website when different content types can have such different implementations, even when they’re so similar.

WordPress has long held a high standard for maintaining backwards compatibility. Not just WordPress, its own architecture, but also PHP versions. It has only been quite recent that WordPress officially dropped support for PHP 5.4 while on one hand. It’s great for backwards compatibility. On the other hand, it’s meant that hosts have had little incentive to keep the servers up to date.

In recent times, WordPress has introduced ways for plugins to require a minimum WordPress version and a minimum PHP version as plugins increase the minimum requirements for their installation. Some of the cheap hosts have been left behind. Living, website’s stuck with plugins that can’t be updated if these plugins have bugs or vulnerabilities in those earlier versions that could leave sites broken or vulnerable to hackers.

WordPress’s commitment to backwards compatibility has led to complacency amongst some hosts. Unfortunately now as much as ever, it’s important to invest in quality hosting.

Stop. We’ll take a look at the code base. WrodPress is old being founded in 2003. So that’s almost 18 years. It’s been around at this point as times have changed and coding standards improve. So too has a lot of WordPress’s code base with many functions being deprecated in favor of better ones. But with their commitment to backward compatibility, most, if not all of these deprecated functions remain just that deprecated, they’re still sitting around in the code base just in case some very old site is still using them.

I wouldn’t say WordPress is bloated, but there’s plenty of code in there that probably should be removed. This is one of the things that ClassicPress has done being a hard fork of WordPress 4.9, they’ve removed many of the deprecated functions and old code that’s no longer needed.

Not everything has improved however, WordPress heavily relies in global variables, which pollutes the global namespace. So you may need to be careful what you call your variables, particularly in functions that use hooks. The best way to check for this is to use the WordPress PHP coding standards, which will highlight variables that you’re using that may cause conflict with some of the core global variables.

You’ve probably seen that template hierarchy diagram before. It’s a wonderful mess of spaghetti. That actually makes a lot of sense. Once you’ve built a few sites. The problem is that it doesn’t really reflect how templating should work for most websites on different pages. They will almost always be a set of global elements that will be present on every page.

Yes. WordPress has functions like get template part. But you’ll still end up repeating yourself a lot across the many different template files, making things really hard. If you need to make a significant change across the board, the best way to try and counter this inefficient template hierarchy is to try and build a template wrapper function.

There are a few themes out there, like roots that have figured out how to do this really well. And I actually did a talk a couple of years ago, demonstrating how to do this. And if you want to take a look into that in a bit more depth, there’ll be a link on screen.

WordPress naturally has a very tight tie in to wordpress.org, but in some ways it’s taken too far. WordPress assumes that every plugin on a site has been installed from wordpress.org. It means that if you intend to develop a custom plugin or theme, you need to be careful about the folder name, otherwise WordPress may try to override it with the plugin or theme of the same name.

That’s hosted on wordpress.org. If you want your custom plugin or theme to be hosted elsewhere, for whatever reason, such as on GitHub, you’ll need to use filters to change where WordPress looks for the plugin to be hosted. There are some ways to make this easy, like the edd licensing class, if you’re distributing your plugins or themes with easy digital downloads.

I believe Fremius has something similar. And then there’s also some GitHub updated classes out there too. However, this isn’t foolproof as it requires the plugin or theme to be active for the filter to run. For instance, instead of something more logical, like an option in a file header. That then takes us to why something like EDD or Fremius is even necessary.

And that’s because you can’t have paid plugins or themes on WordPress.org, they all are free to download. That’s fine. If you just have a plugin or a theme as a hobby, but if you’re plugin grows, it can be difficult to maintain the plugin, to cater for changes to WordPress core and handle support queries and especially, so if you’re not getting any financial return from your plugin, but expected to keep working on it, a lot of plugins have opted to go the freemium route with a free plugin on wordpress.org and sell a premium version with more features away from WordPress at all.

I think it goes without saying that not having paid plugins and themes on WordPress.org has made it harder for people to make a living from building WordPress products and lowers the quality of the plugins and themes available on WordPress.org.

WordPress uses SVN for version control for core and for themes and plugins. SVN is a centralized version control system, which means it’s only really in one place. I wish that WordPress would use Git, and they do use GitHub for more modern projects like Gutenberg, but WordPress has actually been around longer than Git.

So it wasn’t even an option at the time, unlike it, where you can commit locally and push your commits up to the server with SVN, a commit is committing directly to the server. It can be quite painful to use. Especially if you’re used to dealing with Git, if you have a plugin hosted on wordpress.org and you don’t want to deal with SVN, you can use something like Absera to handle the SVN side for you while only dealing with Git yourself.

WordPress is licensed under the GPL, which is a copyleft license effectively. What that means is that anyone can use WordPress. However, they like. That’s cool, but it also means that any derivative works inherits the license, and that means themes and plugins. In some ways, this is a good thing as it makes it easy to foot plugins and make them better, like how we commerce is a fork of Gigoshop.

But what it also means is that. People are more than welcome to redistribute your, your work as their own, including paid work. This has seen plenty of GPL clubs crop up reselling premium plugins at dirt cheap prices. Technically it’s mainly only PHP code that inherits the GPL and images, fonts, et cetera don’t.

As well, lhey may be used by your plugin or theme. They’re not dependent on WordPress in any way. So it’s entirely legal to license your work under a split license where the code is GPL and the other resources arent what this has led to is some zealous gatekeeping in the community. If you wants to publish your plugin on wordpress.org or speak at a WordCamp, for example, everything must be GPL.

Envato, for example, has allowed authors to sell their plugins or themes under a split license. So all Envato employees have been barred from speaking at WordCamps and WordPress meetups while they remain employed there, which is honestly disappointing. Thankfully, this is not an official WordPress event.

Otherwise I might not even be allowed to reference this in a talk 12 seconds later.

The new block editor is not without its issues either. The block editor is built using React, which is a JavaScript framework, which is very different from PHP and even jQuery, which has been the foundation of almost every part of WordPress up until this point, React to the steep learning curve. And while developing a block doesn’t require an extensive understanding of React.

It does significantly raise the barrier of entry as developers need to understand JSX and compilers such as Webpack to even get started. And it doesn’t help. The documentation can be a little lacking sometimes. Thankfully there are some options out there for the traditional developers, advanced custom fields and Genesis custom blocks.

Are just some of those, uh, that allow you to create custom blocks using a combination of PHP and a UI. There are plenty of other issues with the block editor as well, such as poor accessibility, but I think we might just leave it there for now.

I’ll finish with some comments, not on WordPress, the software, but its ecosystem particularly of late, there seems to be a monopolization of the WordPress ecosystem. It’s to be expected in a capitalistic market, but it’s also a shame that ecosystem is becoming less diverse and more and more controlled by a few big players.

Some recent acquisitions include Yoast just acquiring, Duplicate Post. Automatic acquiring Prosperous, WP engine acquiring Genesis and Flywell Awesome Motive acquiring all in one SEO, Liquid Web, acquiring The Events Calendar. And I Themes acquiring Restrict Content Pro obviously there’s no way of knowing for sure, but I think it’s safe to say that some of this has happened because wordpress.org does not host paid products.

There’s also the issue of Automattic and the WordPress trademark by virtue of Matt Mullenweg running both Automattic and the WordPress foundation. Automattic have been given an exclusive right to use the WordPress trademark effectively positioning themselves as the official WordPress authority when that’s not necessarily the case recently Automattic entered the custom website development space.

And this led to a lot of backlash because of the way that they are able to position themselves. I think it’s fair to say that Automattics use of the WordPress trademark hurts the WordPress community. I for one was hurt by it when WordPress was first recommended to me, the first thing that came up in search results, when I looked for it was wordpress.com.

And when I soon discovered that you had to pay to even write some custom CSS, I wrote WordPress off as a trash website builder like Wix. And it would be almost a year before I learned about the open-source software that it’s built on. Automattic also has a bit of a monopoly when it comes to contribution to the core WordPress software.

And that has led some people to believe that Automattic effectively controls the direction that WordPress as the software goes. Maybe they do, maybe they don’t, but they certainly have more of a say than anyone else. I don’t say these things to bash on Automattic or Matt, but it goes without saying that there’s a massive conflict of interest here that we should all be aware of.

Thank you very much for sticking around. Hopefully now you have a better understanding of how WordPress works and some of the limitations it has and also how to accommodate them. Of course, this hasn’t been an exhaustive list, just WordPress suck. Of course not. We wouldn’t be here if it did. My name is Camerson Jones and you can find me online most places as Cameron Jones web.