Navigating a Major WordPress Update

This week, a client approached me with two WordPress websites still running version 5.1 (the current version being 6.5.3 at time of posting). With over five years since their last update and more than 20 outdated plugins, addressing this could have been a daunting task.

I know most developers would have the seen this, and had same reaction of “Ouch 😬” and here’s why:

1. Risk of website breaking: Simply hitting ‘Update’ could potentially crash the entire website.
2. Compatibility issues: There’s uncertainty around how many of the plugins, or if the theme, will still work once updates are run.
3. PHP Version conflicts: The site will likely be running on a server with an outdated version of PHP.
4. Missing Documentation: Themes compiled with tools like gulp or webpack may lack proper documentation or repository access , complicating updates.

So, how do you tackle a big update like this?

There are a few steps you can take to ensure you don’t lose any data or break your website completely. This is a very brief overview of the process I take:

1. Full backup: Secure both files and the database of the live site before you do anything else!
2. Local testing: Replicate the site locally using MAMP or similar tools, ensuring your PHP version matches.
3. Version control: Establish a Git repository, committing the original files, and creating test branches.
4. Incremental updates: Begin with WordPress core updates, followed by plugins, themes, and any additional updates.
5. PHP upgrade: If all goes smoothly, consider upgrading PHP to the latest version.

What issues did I come across?

Surprisingly, not as many as I thought, but it did still take at least 2-3 hours per site to get everything running smoothly:

1. WordPress updater didn’t work

The first issue I had was that the WordPress updater simply didn’t work. It froze completely after clicking update and was stuck on this screen:

So I downloaded the latest version from wordpress.org and manually overwrote the core files. That got everything up and running with the latest version of WP.

Because it’s such a big update, it also required a database update which WP took care of, but it’s here you want to be careful about having a backup of your databse on standby.

2. One of the plugins no longer worked

After updating all the plugins, I found that one had caused a critical error. After turning on debug mode it pointed to a plugin called Typeset Tools (for creating custom post types) which had a lot of depreciated code causing fatal errors. This is only because I didn’t have any access to a Pro License for Toolset, so I moved all the custom post types and taxonomies to ACF .

3. Some of the code in the theme was causing critical errors with PHP 8

As well as the above critical error, there was some PHP code in functions.php which no longer worked with newer versions of PHP, so that needed to be re-written. (See above screenshot)

4. The theme had no documentation

I also needed to fix some of the CSS on the site, however the theme is using SCSS. There was a babel.gulp.js file and a package.json file, but no documentation on how to run it. I tried what I know with my knowledge of gulp and npm, but kept coming up against too many critical errors.

I moved everything across to my own gulp set up so I could get the SCSS and JS compiling nicely again.

5. Some of the ACF fields had stopped working

In the last few months ACF had released a security update – you may have seen the following notice in your WordPress:

This meaning any fields with HTML such as iFrames (such as YouTube embeds) in them had stopped working. This requires some work to the custom fields within the template to make sure their videos were showing up correctly.

The most important thing to take away from this – back up your site!

Whilst none of these were particularly difficult for me to fix, they can be time consuming to debug, and can be especially time consuming if the updates have been done on the live site with no backup and no record of what has been updated.

When we make a backup that comes with all the version numbers of every plugin and theme, so if worst comes to worst, we can roll back to a version that works.

I cannot express this enough, of all the steps above, backing up your website is number one!

If you have any questions or concerns about your current WordPress site, or would like a free 1 hour audit, I’d be happy to take a look! Drop me a line on hello@joloveridge.co.uk

Some of your questions and concerns answered:

I realise there’s quite a lot of jargon and information to take in above, so hopefully here I can answer some of those questions you might have:

How can I check if my WordPress site needs updating?

When you log in your website, you will see in the top bar there is a little refresh symbol. If there is a number next to it, then there are updates to be made.

You may also see down the left hand side a ‘Plugins’ link with a red number next to it. That indicates how many plugins that need updating.

Another place to check (if your version of WordPress is 5.2 or above) is in Tools > Site Health. This will give you a comprehensive overview of what needs updating on your site.

What if I can’t see any of that?

The person who set up the site may have switched off the ability to run updates through the WordPress dashboard, or you may not have permissions to do so. This is to protect against any updates happening before backups have been made!

What is a Git repository and how do I know if I have one?

A Git repository is a storage location where your project’s files and their revision history are stored, allowing for version control and collaboration. Git repositories track changes to files over time, enabling you to revert to previous versions, work on different branches simultaneously, and merge changes from multiple contributors.

Whether a Git repository exists or not is dependent on whether one was set up at the beginning of the project. You likely won’t be able to find this out unless you contact your developer.

Where do I find any documentation for my website?

There may well be some documentation included within the theme (whether it’s pre-purchased, or custom), or within the Git repository itself.

Alternatively you may have been provided some by your developer.

I don’t have any documentation, what do I do?

If you don’t have any documentation, then you could request some from your developer (you may have to pay to have documentation written if it wasn’t included in your original contract). 

Even if you don’t end up using the documentation yourself, it’s extremely helpful if you ever need to hire another developer and could end up saving you a lot of money in the long run.

If you are no longer in contact with your developer, you can hire another developer to write the documentation for you, however you will likely also have to pay for investigation work.

I have a WordPress site and some of this sounds scary!

I understand! I’ve been developing with WordPress for 16 years and still come across some surprises. However, if you’re not confident to run the steps above, speak to your developer. They may be able to offer a maintenance agreement so you won’t need to worry about this. 

If your website is currently quite out of date (more than a year or so), I would highly recommend getting a consultation with your developer and discussing the best route of action to get your website up to date as soon as possible, and then look at running regular updates from there.

This is also a service that I offer, so if you would like a free hour consultation to discuss your current website, please do get in touch!