The Pain Points of WordPress: A Developer’s Perspective

Capable developers often prefer using custom built solutions, especially when you’re a developer that is really good at coding. With a custom solution you can create very elegant applications that function extremely well. Nonetheless, developers end up using a CMS such as WordPress even though they strongly dislike the platform.

This article is aimed at those developers and covers many of the difficulties faced when working with WordPress (WP). We’ll outline what those difficulties are and also come up with a suggestion: the help of Plesk, which provides a toolkit for WP that really helps take care of some of the biggest WordPress frustrations.

WordPress developer's pain points

Why developers use WordPress

Make no mistake, WordPress is the most popular CMS on the market for very good reasons. In this section we outline why the CMS is so popular even with experienced developers that can really write their own code.

First, WordPress is super easy to install. All you need is the standard LAMP/LEMP environment – Linux, Apache/Nginx, PHP and MySQL as DBMS. If you have it – you are fine to start installing WordPress.

Customization is just as easy because the WP CMS comes with a huge range of add-ons, including themes to customize the look and feel and plugins that add functionality. You can even build your own theme and experienced developers can also make their own plugins, but this process is more involved.

Perhaps the biggest reason for the popularity of WordPress is, of course, the fact that it is accessible for non-technical users. Once installed WP does not require any coding experience or understanding of software to work well, inexperienced users can publish a website and configure a WordPress instance right off the bat.

What exactly is the issue with WordPress?

Well, the world’s most popular CMS has a lot of issues to put it mildly. We don’t mean to make a fuss about WordPress’s problems but the following is a frank discussion and we hope the development team behind this incredibly popular CMS takes the following points as positive criticism. Here is why we think WordPress is frustrating for developers to use:

Broadly capable, but never excellent

Look, WP had simple beginnings. All it started out to be was a platform for people who wanted to write a blog, and publish their blog. The CMS has completely changed over the years and now no longer resembles its humble beginnings. Some people use it as a basic way to manage a site, as a platform for online stores and even a way to generate static sites.

In one sense it highlights how adaptable the CMS is and we would concur with that statement but the problem with being so flexible is that it becomes difficult to excel at any single role. One way of looking at this is through the lens of plugins: the thousands of available WordPress plugins shows just how people are trying to force WordPress to be something that it simply is not.

Clearly, WordPress is made for this approach from the ground up and obviously the flexibility has a lot of benefits, there’s no doubt about that. But with no strong concentration on a particular task the CMS can struggle to offer a clear solution. This focus on trying to be everything for everyone is leading to problems. We do have to point this out, however: WordPress is still working well as a terrific platform for building blogs.

Hacks and cracks: WordPress can be an open door

In short, WordPress gets hacked around the clock and it is the biggest complaint we have heard about from developers. There is no denying it, the CMS is full of security holes, it just never ends. In part the number of hacks is due to the popularity of WordPress but it is also due to the way in which WordPress is open-source.

Because everyone can view the open-source code of the CMS it enables hackers to find weak spots in the code. We don’t mean to say that open-source code is an incorrect approach, but we do think that the open-source nature of the WordPress CMS is contributing to its endless security problems.

Analysis shows that WordPress sites make up more than a quarter of the internet. The WordPress team knows this and tries to do everything they can to make sure that the CMS is secure, but because development cycles are so quick nowadays it can be tough to fully secure a complex application. And when security efforts fail, millions of websites can be in danger.

We do not have an obvious solution to the WordPress security challenges aside, of course, from the obvious “update your WordPress instance”. Even then the release cycle of WordPress brings unique problems of its own.

Plenty of people say taking care of WordPress security is simple, and it’s true to a large degree but the question is: why should site owners be required to run through a tick list of tasks to make sure WordPress is secure? Why is this security not part of WordPress out of the box?

It is easy for someone to upload an executable file to WordPress, and this option should be restricted by default. It just requires one slightly clever person to upload a file with malicious code in a PHP script and your site is compromised.
Currently, options can be configured in the file system. Instead, WordPress should eliminate this and make the assumption that the file system is “read-only”. Though the core of WordPress does this, plugins do not follow this pattern of behaviour. If you encounter a plugin that changes the config file while it is actively running in production, stop using it. In doing so it indicates a file system that can be written to and in turn an easy way for malicious changes to occur.
By default WordPress allows users to make as many login attempts as they like. This opens the door to a brute-force attack where hackers keep trying random passwords until the login is successful. The WordPress CMS should disable unlimited login attempts upon installation.

This is not an exhaustive list, it’s just a couple of points really. Obviously, a large software solution, especially an open-source solution, cannot be completely invulnerable to attack. But our point is that serious developers are reluctant to use WordPress because it is so vulnerable. Qualified developers would prefer to build a brand new application form the ground up, that can elegantly meet their needs and which can be tightly secured – without worrying about future, unknown vulnerabilities.

Plugins as the source of problems

A good developer does not resort to a plugin at the first challenge. Instead, good developers look to build a solution that is simple and elegant. In contrast relying on plugins all the time is a very different way of thinking.

In the end a plug-in makes it easy to add specific functions to WordPress, which does make the wide range of plugins available for WP a strength of the CMS – but it is also a risk. As much as plugins can make matters quicker and easier, plugins also bring a lot of risk in terms of security while simultaneously constraining you on which WP version you can use while also bloating your WordPress instance at the same time.

Plugins and security

First, we look at the security problems plugins create. One report suggests that over half of the known WordPress security issues stem from plugins. Developers are subject to whatever good practice a plugin maker follows – which may not be all that good. Therefore as a developer you must thoroughly verify a plugin before making use of it. To some extent this process of vetting can remove the time you save with plugins, so consider coding from scratch instead.

Read on about the Pipdig story on Wordfence.com.

Limits to WP versions

Known as “version constraint”, plugins can limit which version of the WP CMS you can run. Now, WordPress is very aggressive with its release cycle, regularly releasing a new update and it often happens that the platform issues several small versions or patches in a given month. It is understandable as the WP team is constantly fixing attack vectors. Yet all these updates have one problem: a WP update can break a plug-in, causing your site to stop working or to glitch up.

Of course you must keep your CMS up to date but the version constraints imposed by plugins can make this a difficult job. Some plugin developers are always testing and updating their plugins, but this small tier of premium plugins do not represent the majority. Outside of these major plugins you are at real risk that a WP version update can break your site.

Plugin bloat

We assume that most developers know that it is important to build lean projects that do not use excess code. Now, some plugins conform to this principle, but many plugins are very bloated because these plugins try to fix every problem a user could possibly have. It is common for a developer to find that a plugin fixes one issue while also offer a solution to fifty other problems not relevant to their site.

Plugins interrupt the WordPress workflow

Finally, another common problem many plugins create is the fact that a plugin can obstruct the user experience in WordPress. It is related to the fact that plugins bloat WordPress. For example, a plugin can completely change how a post is created and pushed through the site.

This results in a problem that WP developers very commonly face, they feel that they need to work “around” a plugin too much, rather than just using the plugin. Inevitably developers put up with this process of working around plugins because a plugin solves a tricky problem of some sort.

Web architecture has moved on

We’ve said before that WordPress has been around for some time. When it was built the developers assumed that a website will be using a single server, alongside a single file system. However, developers are increasingly using what is called a micro-server architecture that makes use of multiple nodes. They do so because this way of working is more scalable and more flexible. But using WordPress on complicated architecture can throw up problems, for example, the almost exclusive reliance on FTP for getting across WP CMS updates.

Modern day developers would obviously think that updating code via FTP is simply archaic. Developers usually use a specific flow of working so that potential issues can be stopped before code goes live. This means development is done locally, code is controlled by version and that code is also automatically tested – all throughout a continuous integration process. So, just uploading new code into an environment that is running short-circuits this method which means that there is a high chance that matters can go badly wrong.

Bigger than the patches issue is simply the assumption that we are working with a single file system on a single node. A multi-node cluster of web servers improves both hardware failure while also increasing performance, which is why the approach is increasingly adopted. WP presents a hurdle, however, as installing a theme or plugin update via FTP means that only one file system can updated in one go. So, with a multi-node cluster you are faced with running this update for every node.

Developers can get around the problem but it remains a difficulty which is not easily solved. Also, the process requires that your file system is writeable which in turn brings a big security concern to the table.

Orphan data and the structure of data in general

At the outset, the structure of WordPress data is straightforward. However, it soon emerges that there is redundant tables in the WP database. For example, why does the metadata need to be separated into two tables: one called “wp_posts” and one called “wp_postmeta”? Is it not better to include all the data in one table? The same goes for the comments table, which has a second associated table for its metadata.

The result is that there is extra data left all over the database. Yes, WP does include some functionality to help reduce the effect of orphan data but the functions do not work when you need to manipulate a row count that is in the thousands. In practice the WordPress functions cause server timeouts and lead to problems with memory and are simply not effective.

Of course you can choose to simply reduce orphaned data by directly writing SQL queries to that effect. But you need to thoroughly understand how the tables are connected so that you can write the correct SQL queries. The degree to which the data is separated in the WordPress database simply comes across as unnecessary.

What Plesk’s Toolkit for WordPress does to improve matters

WordPress Toolkit from Plesk is an easy way to setup and customize a WordPress instance, all from one control panel. You can use it as long as it is installed on your website.

Here are some areas in which WordPress Toolkit helps take care about WP:

Security management

You can automatically close the most obvious security loopholes using the toolkit. For example you can turn of XML to RPC ping backs, make sure your “wp-content” folder is secure and much more. The toolkit displays the security status of your site and flags issues with either “danger” or “warning” which is a recommendation to improve security.

Updating your WP instance

Available as an extra feature in Toolkit 3.x and later, the Smart Updates function is there to help you keep a production site running while updating it simultaneously, without the risk of breaking the site. The tool checks for problems that might occur due to the update and will tell you if there is a risk of some sort.

Cloning

There are a lot of reasons why you might want to make a copy of your WordPress site. For example, you could have a staging site where you test out changes before making it live. Once ready, you’d want to copy over the content of the site.

Or, you could have a public site and you might want to make a copy of it which you don’t want the public to have access to. Another example is professional developers who have a template copy of a WordPress install and who want to just clone it, including themes and plugins, automatically.

We also have clients who simply want to make a couple of copies of a site for various reasons, for example to demonstrate how a site can look differently with some tweaks.

Whatever you reason, the clone tool in the WordPress Toolkit makes it easy to copy everything including the site’s files, the site database plus all the WP CMS settings.

Synchronization

For various reasons you might want to make sure two WordPress websites match up. WP Toolkit allows you to synchronize both the WP database and all WP files, automatically.

If you have a staging copy of your site, while your public copy runs elsewhere, you could want to synchronize sites because you want to copy the modifications you made on the staging site to the live WP site.

Likewise, you might want to copy some production site data to your staging instance so that you can check whether changes made to the staging version plays well with live data. Or, changes made to your staging site caused a change in database tables in which case the toolkit lets you sync just these database changes if you wish.

Another use-case for the synchronization function of WP Toolkit is where a developer has upgraded a staging site to a final version of WordPress and wants to mirror the changes across to a live site.

You’re at option to synchronize the entire WP CMS, or just certain parts of it. So, you can mirror WP’s files, its database or indeed both. There’s further granularity on offer as you can choose between synchronizing the entire database or just tables, or indeed tables which are in the source but not present in the destination. You can also mirror individual tables across.