When and How to Update Your CMS and Server

Audience

This article is mostly intended for those who have shared or dedicated hosting environment and a database driven website, such as WordPress, Joomla, or Drupal. Those who use a static site or a cloud based service, like Shopify or Squarespace, probably have their “cloud space” managed by their service provider.

Overview

Regular upgrades of your server environment and website don’t guarantee everything will always be running honky dory, but in my experience they are one of those low effort chores, like scheduled data and file backups, that can help prevent some real disasters. Nevertheless, also like backups, software updates seem to often be neglected for whatever reason (e.g. not prioritized, forgotten about, not automated, etc.). So, unless you are trying to study how security and performance degradation can cause system failure, I strongly recommend you have at least some process in place that installs updates of any components your website and server utilize that have updates released on a regular basis.

When and How

When and How I think depend largely on what you use the server and website for.

How

While you can do updates separately for server software packages and the cms core and extensions, I think unless you really need to do them separately for your particular setup and requirements, I suggest having both server and cms updates done at the same time. This way you can do all the updates with one shot and then test your site once, rather than test and re-test after each type of update is made.

When

In terms of frequency, I consider the following factors:

1. Was there a high priority security update released?
2. Is it a LIVE environment, or is it just for development or a sandbox?
3. Have I already performed the updates on a version of the same site in another environment?
4. What is my post-update testing process, and how much effort does it take?
5. Can I easily rollback if things break?

So, each of those factors play a role in determining the priority of the update and how safely it can be performed. I try to weigh these in when setting up an update timeframe. If, for example, I already did the update on a development copy of the site on a test server, and everything went well, then I feel I can more safely perform that update on the production environment.

Example Setup

Since WordPress is the most popular cms, I will use that for an example update setup.

Server Updates

Let’s assume this is in a shared hosting environment, so there is some control of the server setup, most of it is managed by the hosting provider. In this type of scenario, when I want to update server components, I will look at things like PHP version, which is configurable by version on most providers. The current version is 8.1, but according to this compatibility table, 7.4 is the latest fully supported. 8.0 is in beta support, and 8.1 isn’t even mentioned, so without having a separate development environment to test 8.1 in, I’d probably hold off with that version and maybe even 8.0 and stick with 7.4. If the hosting provider allows easy switching between the versions, and I don’t mind my site going down for a short period, I might try 8.1, then 8.0, and finally fall back to 7.4, if any issues come up during testing. One thing that I often see when updating PHP is warnings that come up on the frontend and/or backend with deprecated functions. Newer versions of PHP drop support for some obsolete functionality, and the cms components might not yet all have been updated to replace those old functions with the ones used in the newer PHP versions. Your PHP might also be setup to not display warnings to your browser, which is how it should be setup in a production environment, so you might not notice these happening. That’s why it’s good to test the PHP updates initially in development or on a local copy of the site.

WordPress Updates

As far as updating WordPress itself and any plugins and themes, you have the option of allowing WordPress update automatically, which is the default, or disabling the feature and updating manually. Since the updates can be done pretty easily manually from the wp-admin side, I would recommend disabling the automated feature, unless you really don’t mind the risk of certain parts of your site breaking. The potential of breakage I think can generally be attributed to the amount of plugins and customizations your site may have. If you’re running on a standard WordPress theme with minimal plugins, I think the chances of things breaking will be lower. An update to core where there are no customizations and plugins should not cause any issues.

To opt out of the automated core updates, you have to modify the wp-config.php file in the root of the site and add the following line:

define( 'WP_AUTO_UPDATE_CORE', false );

You can do this with an FTP program like FileZilla or directly through the hosting provider’s web panels, especially if they have something like cPanel.

To opt out of the automated theme and plugin updates, you need to add the following filters to your functions.php file in the root of your active theme:

add_filter( 'auto_update_plugin', '__return_false' );
add_filter( 'auto_update_theme', '__return_false' )

Now, the automatic core, plugin, and theme updates can also be disabled with a plugin, but since these changes are so simple, I really recommend just adding those 3 lines of code :) If you really wish to use a plugin, there’s something like Easy Updates Manager, but now you have another plugin that you need to maintain (and update).