WordPress: It Ain’t Perfect – but Neither Are the People Who Use It

WordPress has become a behemoth in the past 6-7 years. As with any huge project, it receives plenty of praise and lots of criticism.

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.

Let’s analyze Jetpack as an example.

Here are some of the points I would consider when weighing the use of a plugin:

• It has over a million active installs which means that the data we are seeing is representative.
• It is developed by Automattic (not visible in the screenshot), which means the code is definitely 100% WP standard and safe.
• It has a lot of 5 star ratings, which is a good sign.
• It was last updated about 10 days ago (at the time of writing) and looking into the changelog it is obvious that it is usually updated once a month.
• The average score of 3.9 does raise a flag in my mind. It’s not horrible, but it is low enough to warrant reading a few reviews.
• I also like to keep in mind that anything made by large companies (indeed anything that is popular enough) will receive a disproportionate amount of unjustified negative comments. Microsoft and Apple are good examples of this. So a contributing factor in the 3.9 score is definitely that it is popular and made by a large company.
• A lot of the 1 star comments probably have nothing to do with Jetpack. “I’ve lost all my data” is probably not true – these are usually people freaking out over 500 error pages. This is not to say that there aren’t legitimate concerns but the most grievous ones seem to be non-issues.
• I sometimes look into a plugins codebase to see how organized it is. This is a great measure of the developer’s abilities. I appreciate that not everyone has the coding knowledge to do this, but if you do it is a great way to weed out the bad ones.

As always, you can do a lot yourself. If you are worried about security make sure everyone has proper passwords and no one is sharing login details via email unnecessarily. Take a look at plugins like iThemes Security, which offer multiple layers of safety and read articles like Hardening WordPress to find out everything you can do.

Overall: Yes, security is an issue with WordPress. Just like it is an issue with Drupal, Joomla, custom built websites, Facebook, Twitter, Google, your online bank, PHP and MySQL itself and your desktop computer. Security is an issue with everything and it affects WordPress just like anything else.

WordPress’ core is very safe but you need to be careful about which plugins and themes you use. As long as you do your due diligence and use some security-specific tools to monitor and re-evaluate your website from time-to-time you will minimize your chances of getting attacked.

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.

Properly coded products are concatenated and scripts and styles minified. This means that initially all these files are separate for ease of use but when the product is packaged all the files are merged into one file and minified. This saves space and can substantially decrease loading times.

On the other hand, WordPress could do more. It has a wonderful way of enqueueing these assets, making sure that dependencies are pulled in correctly. What the system lacks is a way to concatenate and minify all files used by an installation. Even if theme and plugin authors use the method above, if you have a theme and 10 plugins, that is potentially 10 JS files and 10 CSS files.

It would be great if these files – all from different products – could be concatenated and minified within the WordPress system. There are indeed plugins for this like MinQueue but whether it works or not is hit-and-miss. A standardized way of creating stylesheets and Javascript files, along with an internal concatenation method would solve some of these issues at least.

Finally, you can take matters into your own hands and speed up your website with a couple of tools. You could use Regenerate Thumbnails to regenerate your images to make sure that they are used at optimal sizes. You could also use W3 Total Cache for caching, which could make a huge difference to the time it takes your site to load.

You should also look into a CDN like Amazon Cloudfront. By uploading your images to Amazon S3 and using Cloudfront to serve them from a CDN you can speed up your image loading times considerably.

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.

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.