The platform does indeed deserve the praise it receives, but no system is perfect – a lot of the constructive criticism is well-founded.

In this article I want to focus on the criticism WordPress receives and apply a dose of clarity to each issue. The goal is to help you better understand the problems within WordPress, why they are there and what we and WordPress contributors can do to make things better.

General Guidelines

Before we get into specific issues, let’s take a little detour into two general issues. I think every criticism of WordPress has three sides.

Most issues can split the blame between three areas:

● Plugin/Theme issues
● Subjective reasoning
● User laziness

Plugins and Themes

Many of the issues below will be completely, or in-part caused, by bad plugins and themes. While the direct blame lies with the authors of these products it would be unfair not to point out WordPress’ role in this.

WordPress has the ability to monitor and regulate plugins and themes in its repositories. It is impossible to weed out every single problem, but stricter policies and more rigorous checks could prevent a lot of issues from happening.

Implementing a standardized mechanism for plugin development could also go a long way to ensure higher quality in the repository on average. So, at the end of the day, when I say: “This is not WordPress’ fault, it’s because of a sloppy plugin” I always also mean: “But it would be possible for WordPress to do better.” I won’t always specifically state this, but I believe that even in these cases the blame is shared.

Subjective Reasoning

I think it is wise to always try to debate with yourself and think of reasons why you may be wrong. Many criticisms cited against WordPress are kind of like: “My Kia is slow.”

First of all, “slow” is a relative term. It means nothing unless you specify a frame of reference. If you meant to say: “My Kia is slow because it has a top speed of 140 miles per hour” you’re misguided, to say the least. The fact is, 140 is well enough for every-day use – and probably way too fast even.

If you mean: “My Kia is slow while I’m on the racetrack” your point is valid, but what the heck are you doing in a Kia on a racetrack?

If you mean: “My Kia is slow and the top speed seems to be 50 miles per hour” you are totally right – something is wrong with your car and you should take it to a mechanic.

The point I’m making is that you should always take a look at what the context and the use case is. Just like any other tool, WordPress was built for a specific task. You can’t expect it to behave perfectly in radical environments.

User Laziness

If you own and operate a website it is your responsibility to know how your website works and what you can do to make it better. There are no instant solutions to problems. A security plugin won’t solve all your security issues, a speed-up plugin won’t reduce your load times to the lowest point, and so on.

WordPress is not a magic wand that makes all issues go away. It is a foundation for building excellent sites, just like the foundation of your house. You still need to add plumping and electrical for a solid starting point (this would be your theme) but you also need those little finishing touches that make your home perfect (these would be your plugins).

Expecting WordPress to be a cure-all for any ailment you throw at it is like expecting the stonemasons to furnish your bedroom.

Security and Getting Hacked

This is the number one issue I see everywhere. I want to make it very clear that this falls heavily into the “plugin/theme problem” category.

WordPress’ core is extremely safe and well-protected – there is just no question about that. If a vulnerability is found it is promptly patched and new versions are pushed out to fix them.

One issue in WordPress security is user laziness.

If you don’t take the time to update WordPress thinking that it doesn’t really make a difference, don’t blame WordPress for your laziness.

The other issue is plugins and themes, which don’t employ best practices or contain security loopholes due to sloppy development. As I mentioned earlier, the direct blame lies with the product authors, but WordPress could do better.

So what can you do to identify bad plugins? I like to work with tried and tested plugins, which have plenty of reviews and are updated frequently. A developer who takes the time to support the product is less likely to be a tardy developer.

Website Speed Issues

Another common issue with websites is that they are slow. This one is difficult to get to the bottom of because of all the factors involved.

First of all, the issue is similar to my Kia example. Slow is a subjective concept and you need to take your surroundings into account. How large is a fully rendered page of your site, just how slow is slow?

WordPress is pretty speedy by default but you do have to take into account that it is a large framework and will never be as fast as a properly coded custom site or a static HTML page, even when cached. Despite this, it can still be lightning fast, we may be talking about tens of milliseconds per load for simpler websites.

What slows WordPress down is plugins and themes again, I’m afraid. Premium themes especially are culprits. Many of them include everything, even the kitchen sink, and load so many assets you don’t use it sometimes hurts my eyes. Tens of Javascript files, tens of stylesheets along with lots of images can quickly bump loading times into the 5-6 second range. Plugins also tend to add another layer of loading times by using their own scripts and styles

In some cases the blame lies with developers. It is not OK for a theme to link to 15-20 separate Javascript and stylesheet files. These increase loading times inordinately and can actually be solved pretty easily.

Site Migration Is a Major Pain

This one depends on your site architecture. If you know your stuff, or you have a professional web developer, this issue can be solved completely, but in general this one is completely true – site migration is, indeed, a pain.

The larger issue here is that it is a pain for any other platform. If you have a custom-coded website it may even be a bigger pain since there are no tools available to check for things that went wrong.

Migration is mostly a pain because few people understand what needs to happen to make it painless. First of all, you need to know that your website is a collection of files and a database. If you transfer both of these properly you may still need to know how serialization works.

If you change your URL from “mydomain.com” to “mywebsite.com” and you use a search and replace tool on the database it won’t work because of serialization. You need to un-serialize all serialized strings, do the search and replace and then serialize them again (WP-CLI can do this). The point is that this is just one of the things you need to know – and there are a few.

Could WordPress do better? Sure, but this really isn’t something lead developers and contributors should be focusing on. There are plenty of import/export options, but heavy-duty stuff like moving to a new server and changing URLs should really be handled carefully by professionals. Your best course of action here is getting a developer who knows what he/she is doing and your life will be a lot easier.

That said, there are some things you can do without having to complete a WordPress course. Moving all your images away from your server is a good start. I mentioned Amazon S3 before. I quite like moving stuff there. When you move a large site the database and files (all plugins and your theme) could make up a a few megabytes, say 30MB if you have large plugins in there. Your media files could add up to 20GB over time. Downloading these and then uploading them to a new server is such a pain.

Another method is to make sure everything you do is standardized. If you use custom fields use the same naming structure. If you decide to camel case titles, always do so, and so on. This makes it easy for developers better as your is more website more predictable.

Clients Don’t Use It

The issue here is that no matter what system you build for them, clients will not use the backend as intended. I haven’t done client work for a while but I can certainly empathize with this one. It is one of the most frustrating issues in web development.

However, this isn’t really WordPress’ fault. Educating your client is in part your task. In addition, you should be aware of your client’s needs and should build an admin which adheres to this. It’s easy to lump this one in the “clients being a bit silly” basket, but the real issue could be you as a developer not being able to anticipate their needs. That being said, this really is one of the hardest things to do and I’ve messed up my fair share here as well.

Could WordPress do better? In this case the answer is a clear “yes.”
The admin interface is not bad and is modular-ish, but a lot could be done to allow for more extensive customizations to make it less scary for newcomers and corporate users. Take a look at Jason Schuller’s Nice Admin Designs to see what I mean.

Right now, this level of detail is not impossible but is hard to do and requires more work than should be necessary. However, it is a good example of how only laziness – or not having a large enough budget – is the only thing holding you back.

WordPress Core Code Is a Mess

You know, this is a good one because it shows very well how misguided people can be, and how much they rely on other people telling them what is important and what isn’t.

Is the WordPress core code a mess? Yes, it is. And as a user you care why exactly? As long as the code is safe and it is fast and you never-ever have to take a look at it, why is this an issue at all?

Let me clarify this a bit. I think we need to define what “a mess” is. WordPress’ code is inconsistent, not a mess. This has historical and practical reasons. The code being “a mess” contributes to the almost unparalleled stability of the core systems.

WordPress started out 10+ years ago during a time when object oriented approaches and other higher level techniques were not especially prevalent in web technologies like PHP. Since then, WordPress has borrowed from these great methodologies, but has not modified many systems to ensure backwards compatibility.

Due to this you will find some terribly named functions, some sections which use procedural code, and some which use object oriented approaches. Some objects have partial overlaps, some are completely independent, sometimes CSS follows the correct guidelines, and sometimes it doesn’t.

What really counts is not this. From an end-user’s point of view it’s stability, speed and security that defines the quality, and we have them all in the core WordPress software. From a developer’s point of view, it’s documentation more than anything else and we have plenty of that as well.

Could the code be better? Of course, but this would come at the expense of millions of sites suddenly ceasing to work. Frameworks like Laravel may be able to produce more standardized code but WordPress has millions upon millions of users to think of. The point is that newly written code should follow strict guidelines and we have documentation for everything.

Conclusion

This list could go on and on for a while. I think the best way to see clearly in all of these issues is to be in possession of more knowledge. Almost all issues can be blamed on the three things I outlined above: Subjective reasoning, bad development practices and WordPress itself.

I thought it would be interesting to round things off by reading WordPress: A fractal of bad design and The hate and vitriol of WordPress. The former is heavy-handed WordPress criticism, the latter is WordPress’ defence.

Personally, I tend to side with reason and even-handed thinking, which is why the second article is closer to my heart. The first article is a bit over-zealous in hating WordPress, but this isn’t to say there aren’t any valid points in there, quite the contrary, but the conclusion derived from the points it makes is flawed in my opinion.

Whenever you hear any criticism about WordPress make sure to get the full story and make up your own mind, don’t listen to any one person – whether it’s me, the founder of WordPress, your web host, or anyone else.