The automatic updates for minor versions of WordPress have proven themselves for years. But does it also work with plugin updates? And if so, under what conditions? This question has been investigated by WordPress developer Florian Simeth.

Anyone who has been using WordPress for a while knows: The automatic updates of the core software work quite well and mostly without problems. If there were not the plugins. Typically, the thought of automatic plugin updates makes the hairs on the back of most website maintainers' necks stand up. Anyone who has ever gritted their teeth before clicking 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 does not fail, but the errors lurk somewhere - not visible - in the underground. 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 contribute to new versions of WordPress. Not every plugin project has this power. Most of the free plugins in the WordPressplugin directory are developed by only one person (or maybe a small team). This does not mean that these plugins are bad per se. However, we know from the past that it is mostly the plugins that open security holes, making one's WordPress instance an attack surface for hackers.

It can therefore be assumed that the code quality suffers or is tested too little. Why this is so, I do not want to explain at this point longer. But it explains why I quickly click on the update button for well-known plugins like YoastSEO and not for others.

"Basically, you recognize problems of course by the fact that something has already gone wrong," wrote me, for example, the WordPress developer Marc Nilius in an e-mail interview. According to his own information, he currently maintains about 200 WordPress instances and knows his "friends" only too well.

Now Yoast certainly has a big team behind its own free YoastSEO-plugin, which is active on over five million WordPress websites. For the company's flagship, it does everything it can to make sure nothing goes wrong. This is associated with effort. An effort that a developer alone may not be able or willing to handle. So what can be done?

Ways to Minimize the Risk from Plugins

1. Do Not Use Old Plugins

"Democratizing Publishing" is a pointed tagline for WordPress. That anyone can just quickly set up a WordPress website is a brilliant thing, but automatically leads to those people wanting to expand site at some point. And that with plugins. Since they usually can not program themselves, they look in the eternal WorldWideWeb for remedies. And there are plenty of them. 

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

Of course, there are also positive examples. For example, there is a huge company behind WooSidebars. Nevertheless, the WooCommerce plugin did not receive any updates for quite some time. It was not tested with the latest WordPress versions, but still works fine in many cases. How much longer? Earlier comments in the support section already indicated an end. However, the user did not notice anything about it. During installation, only a small, inconspicuous notice shows this grievance. A dangerous thing.

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

2. Do Not Adjust Plugins Yourself

To save development time, official as well as unofficial WordPress plugins are often simply adapted by 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 the own changes.

"Customized plugins often depends too much on theme functionalities", Marc also knows. If something changes in the theme, the plugin does not run correctly anymore. So there are many problems. But 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. Admittedly, one could ask whether automated tests of new versions are performed. But who does that? Many WordPress users do not even know that such a thing is possible. In addition, such tests (if they are performed) often have nothing to do with live situations.

Which is also understandable from the point of view of developers. Who tests every plugin with every possible WordPress theme? Or every plugin with every other plugin? You can't. You can't trust those who develop WordPress plugins either.

Here too, it is sometimes impossible not to use "bad" plugins, because they are simply not always recognizable. Although the quality rating is already the first hurdle for many users, you should at least actively test new plugins yourself before you integrate them on a livesite. But more about that in a moment.

Why Automatic Plugin Updates Fail

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

Here are some possibilities:

1. PHP-Fatal-Error: The website does not work at all because of a serious error.
2. The Plugin does not work (anymore) with other Plugins and/or the Theme. This manifests itself in several ways:
   a) functions are no longer available or
   b) the layout changes in the frontend.
3. Non-existent backward compatibility makes 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 layman cannot check if the code quality is good, a system would have to be created that can do that. The question is: Would something like that work? And the answer is quite clear: Yes!

There is a small WordPress team already working on such a system. It is called Tide. Tide's vision is to perform automated quality tests for all WordPress plugins and themes and to make these test results visible for the authors as well as for the users of these plugins and themes.

It's not ready yet, but in the future Tide will help laypeople better identify what kind of WordPress plugins they are installing. Until it is, you have to follow the plugin metadata that is displayed on wordpress.org in the plugin directory for every single plugin:

1. The date of the last update. Frequent updating can indicate an active development process. In most cases, the developers then also takes care of fixing bugs.
2. Number of installations. A very high number not only indicates the popularity, but can also be an indication that the authors earn money with the plugin (e.g. via a Pro version). This creates a certain pressure on the part of the manufacturer. He certainly has an interest in ensuring that the free plugin also works without errors.
3. Tested until. This is also only a version number that can be adjusted by the manufacturer at any time without having to be proven by a third party. However, a current version number is an indication that the plugin is regularly updated.
4. PHP version. While it's nice that developers continue to support low version numbers of PHP, a higher version would be safer.

Automated Browser Tests

Now it becomes a bit more difficult. Especially for those who do not have any programming knowledge. If you depend on important functions, you should test them regularly - preferably automated, of course.

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

Functional Tests

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

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

Visual Regression Testing

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

Since BackstopJS also gives a detailed, machine-readable report with a distinction value in percent, you could, for example, be notified by email when there has been a significant change in layout.

Rollback

Let's say all the updates were done and the automatic tests failed. What to do? Of course, backups can be imported automatically. But this only works in three cases: 

1. If the host 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 all 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 lack of resources on the server.

Other Solutions?

Of course, my view is only one of many. There are other, mostly more expensive solutions. For example, instead of importing a backup afterwards, you can make a copy of site beforehand(staging concept as with Raidboxes, in addition to the WordPress backups) and perform all possible updates and tests with it. If everything goes well in the test, the updates can finally be installed on the livesite as well. Then of course (mostly) completely automatically and without raised hackles.

Another idea would be to simply have WordPress create static pages. Then the site would be a bit more independent from the actual core. Plugins for this purpose already exist for eight years: WPStatic, for example. But again, this doesn't work for every use case, certainly not for highly dynamic sites like online stores.

Conclusion

No matter how you do it, it is wrong, right? No! In the end it depends on your own website, on your wishes and of course on your wallet. If you don't run critical sites and it's okay for a website to throw errors, you'll do fine with auto updates.

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

Probably, automatic plugin updates for most, small sites but anyway relatively smoothly. Those with larger sites usually have more financial resources to take appropriate action. Everyone in between will have to find their own solution.