Automatic updates for minor versions of WordPress have proven their worth for years. But does this also work with plugin updates? And if so, under what conditions? WordPress developer Florian Simeth investigated this question.

Anyone who has been using WordPress for a while knows that the automatic updates of the core software work quite well and usually without any problems. If it weren't for the plugins. Typically, the thought of automatic plugin updates makes the hairs on the back of most website administrators' necks stand up. Anyone who has ever gritted their teeth before clicking on the update button knows what I'm talking about.

There is no fundamental certainty that the updates will go through correctly. Not even if the update itself doesn't fail, but the errors are lurking somewhere - invisibly - in the background. Most of the colleagues I interviewed would not perform automatic plugin updates, at least not for all WordPress plugins. But why is that actually the case?

Automatic plugin updates: the risks

Hundreds of volunteers work on new versions of WordPress. Not every plugin project has this power. The vast majority of free plugins in the WordPress plugin directory are developed by just one person (or perhaps a small team). This does not mean that these plugins are bad per se. However, we know from past experience that it is usually the plugins that open up security vulnerabilities and make your WordPress instance an attack surface for hackers.

It can therefore be assumed that the code quality suffers or is tested too little. I don't want to explain why this is the case at this point. But it does explain why I quickly click on the update button for well-known plugins such as YoastSEO and not for others.

"Basically, you can recognize problem cases by the fact that something has already gone wrong," wrote WordPress developer Marc Nilius in an email interview. According to his own information, he currently maintains around 200 WordPress instances and knows his 'Pappenheimer' only too well.

Now Yoast certainly has a large team behind its own free YoastSEO plugin, which is active on over five million WordPress sites. For the company's flagship site, it does everything it can to make sure nothing goes wrong. This involves a lot of effort. An effort that a developer alone may not be able or willing to make. So what to do?

Ways to minimize the risk from plugins

1. do not use old plugins

"Democratizing Publishing" is a great motto for WordPress. The fact that anyone can quickly and easily set up a WordPress website is a brilliant thing, but it automatically leads to these people wanting to expand the site at some point. And they do so with plugins. As they usually can't program themselves, they search the eternal WorldWideWeb for a remedy. And there are plenty of them. 

There are currently almost 55,000 extensions in the WordPress plugin directory alone. Whatever works is used. Without paying attention to whether the plugin is being further developed or whether it is compatible with the current WordPress version. This is not always correct and ultimately often leads to a healthy distrust of updates. This is because such plugins often tend to stop working at some point. Even if this can take a few years.

Of course, there are also positive examples. WooSidebars, for example, is backed by a huge company. Nevertheless, the WooCommerce plugin did not receive any updates for a long time. It has not been tested with the latest WordPress versions, but still works perfectly in many cases. For how much longer? Earlier comments in the support area already indicated an end. However, the user was not aware of this. During installation, only a small, inconspicuous notice indicates this problem. A dangerous thing.

Of course, when you start your blogging career, you often don't have the money for individual development. For these people, there is sometimes no other alternative. Nevertheless, you should keep in mind that - due to the security risks mentioned above - no outdated WordPress plugins should be used.

2. do not customize plugins yourself

To save development time, official and unofficial WordPress plugins are often simply adapted by their own developers. If the version number or the name of the plugin is not changed, WordPress offers an update, although this may not be carried out because it would otherwise overwrite your own changes.

"Customized plugins are often too dependent on theme functionalities," Marc also knows. If something changes in the theme, the plugin no longer works properly. So there are many problems. However, doing everything yourself from scratch, i.e. only using your own developments, is not a real alternative here either.

3. do not use bad plugins

What is a "bad" plugin? This question is not easy to answer. Especially not for the layman. Of course, you could ask whether automated tests are carried out on new versions. But who does that? Many WordPress users don't even know that this is possible. What's more, such tests (if they are carried out) often have nothing to do with live situations.

Which is understandable from the developer's point of view. Who tests every plugin with every possible WordPress theme? Or every plugin with every other plugin? That's not possible. You can't trust those who develop WordPress plugins to do that either.

The same applies here: sometimes it is not possible to use "bad" plugins because you simply cannot always recognize them. Although the quality rating is already the first hurdle for many users, you should at least actively test new plugins yourself before integrating them on a live site. But more on that in a moment.

Why car plugin updates fail

The fact is: You can't simply not use WordPress plugins. The problems mentioned above will always exist. Another solution must therefore be found. So the question you have to ask yourself is: "How can you - despite all the problems - still carry out automatic updates for WordPress plugins?". And this question inevitably leads to the next one: "What could go wrong?"

Here are some possibilities:

1. PHP fatal error: The website no longer works at all due to a serious error.
2. The plugin does not (or no longer) work with other plugins and/or the theme. This manifests itself in various ways:
   a) Functions are no longer available or
   b) The layout changes in the frontend.
3. Non-existent backward compatibility makes a rollback difficult.
4. The database is so large that a backup would take a very long time.

Solutions for successful plugin updates

Recognize bad plugins

Let's start with the users. How could they recognize a "bad" plugin? Since the layperson cannot check whether the code quality is good, a system would have to be created that can do this. The question is: would something like this work? And the answer is quite clear: Yes!

The great thing is that a small WordPress team is already working on such a system. It's called Tide. Tide's vision is to carry out automated quality tests for all WordPress plugins and themes and to make these test results visible to both the authors and users of these plugins and themes.

It's not ready yet, but in the future, Tide will help laypeople better recognize what kind of WordPress plugins they're installing. Until then, you'll have to stick to the plugin metadata, which is displayed on wordpress.org in the plugin directory for each individual plugin:

1. The date of the last update. Frequent updates can indicate an active development process. In most cases, the developers then also take care of bug fixes.
2. Number of installations. A very high number not only indicates popularity, but can also be an indication that the authors are earning money with the plugin (e.g. via a Pro version). This creates a certain amount of pressure from the manufacturer. They certainly have an interest in ensuring that the free plugin also works flawlessly.
3. Tested to. This is also only a version number, which can be adjusted by the manufacturer at any time without this having to be verified by a third party. However, a current version number is an indication that the plugin is updated regularly.
4. PHP version. While it is nice that developers continue to support low PHP version numbers, a higher version would be safer.

Automated browser tests

Now it gets a little more difficult. Especially for those who have no programming knowledge. If you depend on important functions, you should test them regularly - preferably automatically, of course.

Puppeteer is a NodeJS library that provides a high-level API to control the Chrome browser via the DevTools protocol. Puppeteer runs headless by default, but can be configured to open the browser so that you can see what is happening.

Functional tests

There are many use cases for such tests. If you have an online store with WooCommerce, you can use it to check whether products can still be added to the shopping cart. Or whether forms can still be sent.

Of course, not all cases can be covered. In most cases, however, a small automatic test is more effective than a simple visual check. After all, it is not always possible to test all the functions of a site after every small update. Especially if it is very extensive.

Visual regression tests

A "visual inspection" could also be automated with today's tools. This works relatively easily with BackstopJS, for example. The configuration is done quickly via a JSON file. A backstop test in the console is enough to start the comparison. Finally, the tool opens a browser window and displays the differences.

Since BackstopJS also provides a detailed, machine-readable report with a difference value in percent, you could, for example, be informed by e-mail if there has been a significant change in the layout.

Rollback

Let's assume that all updates have been carried out and the automatic tests have failed. What should you do? Of course, backups can also be imported automatically. But this only works in three cases: 

1. If the hoster has an interface through which a rollback can be triggered automatically.
2. Or if you have SSH access.
3. And if the backup is small enough. Otherwise the restore will take several hours in the worst case.

Many developers know only too well that most of this is often not possible. Either SSH access is not available in the first place or there are timeouts due to a lack of resources on the server.

Other solutions?

Of course, my view is just one of many. There are other, usually more expensive solutions. For example, instead of importing a backup afterwards, you can make a copy of the site beforehand(staging concept as with Raidboxes, in addition to the WordPress backups) and use it to carry out all possible updates and tests. If everything goes well during the test, the updates can then also be installed on the live site. Then, of course, (usually) completely automatically and without raising any hackles.

Another idea would be to simply have WordPress create static pages. This would make the site somewhat more independent of the actual core. Plugins for this purpose have been around for eight years: WPStatic, for example. But here too, this does not work for every use case, especially not for highly dynamic sites such as online stores.

My conclusion

How you do it is how you do it wrong, right? No. Ultimately, it depends on your own website, your wishes and, of course, your budget. If you don't run critical sites and it's okay for a website to throw errors, you'll be fine with auto updates.

With Raidboxes, you also have the option of activating automatic plugin and theme updates with the Fully Managed add-on. In the settings of your BOX, you can also exclude individual plugins and themes with which you have already had problems from the auto-updates.

However, automatic plugin updates are probably relatively easy for most small sites anyway. Those with larger sites usually have more financial resources available to take appropriate measures. Everyone in between will have to find their own solution.