The reason why I won’t let WordPress automatically update the core software, plugins and themes is this: it is practically impossible to ensure the new version works together with thousands of possible system configuration combinations on the server.
Years ago, when I was still working for a global tech corporation, I could follow how the IT department managed PCs, laptops and phones. All software updates for Windows computers were held back until the selected updates had been tested in a variety of system configuration combinations. The updates were then pushed to company laptops so that we were sometimes forced to update in the middle of a Powerpoint presentation.
Nothing is perfect, but most importantly, the laptops didn’t have problems caused by software updates.
The reason for allowing WordPress server software automatically update itself instantly when a new version is available is convincing: the web site is more secure because all the known holes have been patched. Often, however, also new features are introduced in new versions.
The team that manages the testing and packaging of new WordPress releases is doing an excellent job. I have never had problems with WordPress itself. The worst problems, at least for us, were caused by external factors and system configurations.
Occasionally, WordPress plugin updates have caused problems to a perfectly functioning web site. It has happened to us. Since we don’t allow auto-update, and we know what we have updated, it has been quite easy to identify the guilty plugin, and fall back to the previous version. If we allow automatic updates, it is more difficult and time consuming to discover the problem, and visitors experience problems for longer period as well. It is possible to control exactly how and what WordPress updates.
The final incident that triggered me to share the risks of automatic WordPress updates happened when we updated our test site to 5.3.1 from 5.3. We didn’t update anything else – just the core WordPress. The system went nuts. It looked like random pages were served to web browsers. It took quite awhile to debug, but finally we discovered the culprit. It wasn’t WordPress. It was a caching system we had been testing for a few weeks in this particular web site.
Before the WordPress update, Apache 2.4 http cache system worked fine. We installed the cache after WordPress 5.3 was installed. When WordPress software was updated to 5.3.1, the cache went out of sync. We had to disable the cache, and wait until its own expiration time forced it to clean itself. Then, we could re-activate the cache.
Apache cache runs outside WordPress. The content management system doesn’t have a clue that another software is doing something like that.
Sure, WordPress plugins that can cache content are plenty, but we are trying to avoid a plugin when a solution is available outside WordPress, in the operating system or web server level.
If this cached web site had been a live system, the experience for visitors would have been something they would remember for a long time. It was that weird.
This was a long way to say that web sites have many other software components besides WordPress (plus the obligatory web server, PHP and Mariadb). Even when a new WordPress release has been thoroughly tested, external factors – the specific server configuration – can’t be tested by anyone else but the web site admin.