Upgrading WordPress is easy – just check some boxes and click a button. But it’s actually more complicated than that. Upgrades don’t always go smoothly, and they could potentially break part, or all, of your site.
- What Can Go Wrong If You Don’t Upgrade
- What Can Go Wrong When You Upgrade
- When To Wait on an Upgrade
- Best Practices for WordPress Upgrades
- 3 Recommended Approaches to Upgrading Your WordPress Site
- My Upgrade Process
- What To Do If a WordPress Upgrade Breaks Your Site
What Can Go Wrong If You Don’t Upgrade
- You can get hacked. The longer you go between upgrades, the more susceptible you are to getting hacked. Vulnerabilities in WordPress core, themes, and plugins will always come up. Most of the time, they are fixed quickly, but if you don’t upgrade, you don’t get the fix. Most hacking attempts are automated and not targeting you specifically. So if you think your site is too small or too unknown to be a target, you’re wrong.
- Your site could break due to incompatibility with your host’s software. You typically don’t have control over the software, and if they upgrade software such as PHP and something on your site isn’t compatible with the latest version, your site could break without you doing anything.
- Your site could break due to auto-upgrades of WordPress core, and incompatibility with your theme or plugins. If you’re not on a really old version of WordPress, then you probably have WordPress core auto-upgrades enabled. Oftentimes, an upgrade to the offending theme or plugin has already been released with the fix, and is compatible with the latest version of WordPress – but if you haven’t upgraded that theme or plugin, then your site could break when the auto-upgrade happens. This is why it’s important to keep up with upgrades. The longer you go between upgrades, the more things could go wrong. Also, you should get on the WordPress.org mailing list to get notified of new releases. This way you’ll know to check your site when it auto-upgrades.
What Can Go Wrong When You Upgrade
Whenever you upgrade, there’s a risk of breaking something on the site, or in rare cases, taking the entire site down. Some common instances of things breaking:
- If you made customizations to your theme files without using a child theme, and you upgrade your theme.
- If you made customizations to your child theme, and you upgrade your child theme.
- A new version of a theme or plugin has a bug or incompatibility with something else.
When To Wait on an Upgrade
In some cases, you may not want to upgrade everything immediately. This is particularly true for major upgrades, which often introduce major new features and changes. Minor upgrades have bugfixes and security fixes, and rarely break anything. For WordPress core, a major upgrade has two numbers, such as 4.8. A minor upgrade has three numbers, such as 4.8.1. Themes and plugins may use different numbering systems.
Before doing a major upgrade, you should check reports of people using it. Even with so many people testing it before it’s released, things get overlooked all the time. For example, WordPress 4.8 had some major issues with text widgets. The 4.8.1 release came out shortly after with fixes to those issues. If it’s WordPress core or a very popular theme or plugin, and there’s a major issue, they will usually issue a fix quickly, so you won’t have to wait long.
Best Practices for WordPress Upgrades
Back up before upgrading, make sure you have FTP/SFTP access, do it during off hours, make sure you know what to do if something breaks,
- Make sure you have a recent backup. It’s easy to forget to do this, and if something goes wrong, you’ll have an out of date backup (or no backup). If you use the premium version of UpdraftPlus (highly recommended), it will automatically make a backup before the upgrades are performed, so you never have to remember.
- Make sure you know how to restore a backup. UpdraftPlus has a one-click restore feature, even in the free version. However, if an upgrade breaks your site to the point that you can’t access the dashboard, you will need to know how to restore manually.
- Make sure you have FTP/SFTP and database access. In rare cases, an upgrade can break your site and lock you out of the backend, leaving you with a white screen (sometimes referred to as the “white screen of death”) and without the ability to make any changes to your site in the browser. If that happens, the only way to fix the site is through FTP/SFTP (and occasionally the database), so it’s best to make sure you have access before you start upgrading. The last thing you want is to have the “white screen of death” for your site for minutes, hours, or even days, while you try to find the right login credentials or have to get it from the site’s owner. If you’re working on a site for someone else, this could put you in a really bad spot.
- Upgrade during off hours. If something goes wrong during a low-traffic time of day, fewer people will notice.
- Don’t upgrade multiple sites at once. Managing upgrades on multiple sites with a program like ManageWP or InfiniteWP can be dangerous. If you upgrade multiple sites at once and you’re not checking the sites individually, you could break them all at the same time. It’s much better to do one at a time, in case you need to fix or restore a site. Also, you’re probably using a lot of the same themes and plugins across multiple sites. If one of those has a bug, you don’t want to upgrade it on any more sites than you have to, until you find the fix.
- Know what to do if something breaks. If you’re not comfortable fixing code or know how to restore a backup, consider having a developer on call.
- Test the upgrades on a staging site. If your host has a staging feature, this comes in extremely useful for testing upgrades. Flywheel and WP Engine both offer staging (with the exception of the Tiny plan on Flywheel).
- Open everything in two browser tabs to do an easy before/after comparison. This way, you can keep the first tab as your “before”, and you can reload the second version after doing the upgrades to have an “after” to compare. Not all things that break are easy to notice. Sometimes a feature or widget may vanish and you don’t remember it was there right away. If you do a before and after test, you can notice these things visually without having to think about it. And if something breaks on the design, you know exactly what it’s supposed to look like (and can copy the code from the page source of the “before” page). You should do this for the Upgrades tab (to remember what’s been upgraded so you know what to test for), and key pages on your site (typically the home page, other important pages, and examples of different page/post types). For example, you may want to do this for the Contact page if you have a form plugin that’s being upgraded. You’ll want a post since you’re probably using a different layout and plugins that only affect the blog.
3 Recommended Approaches to Upgrading Your WordPress Site
Most people log into their site, click to the upgrades screen, then select all the available upgrades and hit the Upgrade button. Then if they get the “white screen of death” or see something wrong on the front end of their site, they panic.
This is not the best way to upgrade your site.
If you take some extra precautions, you can save yourself a huge headache. Here are 3 approaches you can take, which depend on your risk tolerance, how much time you want to spend on the upgrade process, and if your host allows staging.
Method 1. Upgrade everything live, all at once.
This is the fastest method, but it is the highest risk of these 3 approaches.
If you do a lot of upgrades at once and you have a problem, it can be harder to tell which one caused it. You’re also doing it on the live site, so there’s a higher chance of a visitor experiencing the issue. If you use this method, you should at least follow the best practices listed above.
Method 2. Upgrade everything live, in batches.
If you spot check your site after upgrading each item, or each few items, then you can narrow down any problems faster. If you have 12 upgrades pending and you do batches of 4 at a time, you’ll know it’s one of those 4 instead of having to check all 12. Naturally, it takes longer when you’re spot checking your site more times in between batches of upgrades.
Just like with Method 1, you’re doing this on the live site, so there’s a higher chance of a visitor experiencing the issue. However, since you’re doing fewer upgrades at a time, you can identify the problem and deactivate or fix it faster. You’re also less likely to have multiple broken things on your site at once. If there happens to be more than one bad upgrade, this is better than upgrading all at once and having to deal with fixing more than one problem at a given time.
Method 3. Upgrade everything on a staging site first.
This is the slowest method, but also the safest.
The ability to create a staging site is a feature common to managed WordPress hosts like Flywheel and WP Engine (with the exception of the Tiny plan on Flywheel). Typically, you can click a button to make a full working copy of your site (aka the staging site) at a different URL. This is also known as “pushing live to staging.” You can use the same login credentials to get into the staging site. Then you can do all of your upgrades on the staging site and test for problems, without affecting the live site. (This is also a helpful feature for site redesigns.) You can also click a button to “push staging to live,” but in most cases I don’t recommend using that button. Some things may have changed on your live site in the meantime, such as new comments or form submissions, and they can be erased when you do that.
Make a fresh staging copy, then upgrade on staging and and check your key pages. If everything works all right, do the upgrades on the live site and check your key pages on the live site. With this method, you have very little chance of any problems affecting the live site, and any disruption to visitors. You can also feel safer about upgrading multiple items at once, because if something breaks, it’s only on the staging site.
My Upgrade Process
I maintain a lot of websites for myself and for clients. I start with the smaller sites that are less complex and don’t get a lot of traffic. Those sites have fewer plugins, and since I upgrade at least once a month, they don’t have many pending upgrades at any given time. I use Method #1 for those.
As a general rule, when there are 10 or more upgrades that I haven’t tested on other sites, I’ll use Method #2 (upgrading in batches). I’ll also use Method #2 when there are major upgrades to a big plugin, such as WooCommerce.
As I go through the upgrades, I’ll keep track of anything that goes wrong and how to fix it. When I eventually get to the bigger sites, many of the upgrades are going to be the same as ones I’ve just done on the smaller sites. With my experience, the automatic backups from UpdraftPlus Premium, and since there are fewer risks due to the other upgrades I’ve already tested, I’m usually confident to use Method #1 or Method #2. For the bigger sites that haven’t been upgraded in a while, or for clients that are more risk-averse, I’ll use Method #3 to be safer.
What To Do If a WordPress Upgrade Breaks Your Site
- Try to fix the theme/plugin by modifying the code.
- Restore that one item to an earlier version. If it’s a plugin, try to deactivate it first. If you’re locked out of the dashboard and can’t get to the Plugins menu to deactivate it, navigate to the plugin folder via FTP/SFTP and rename it (I recommend simply adding a dash to the beginning of the folder name so you can find it easily). You will probably want to use the exact version you were previously using, so it’s best to retrieve it from your latest backup. If the theme or plugin is in the official WordPress.org repository, and the author has kept the older versions, then you can go there to retrieve the earlier version.
- If you upgrade multiple items at once and you’re not sure which plugin broke your site, you can rename all of the recently updated plugins one by one until you find the culprit. You can identify the recently updated plugins by the date modified. If that doesn’t work, you can rename the entire plugins folder. That will deactivate all of your plugins. Then you can restore them one by one until you find the one causing the problem.
- Do a full restore of your site from a backup. This is usually a last resort.
- Report the issue to the theme or plugin author, even if you were able to fix it by modifying the code. If you were able to fix it, sharing the fix will make it very likely to be included in the next upgrade. If you weren’t able to fix it, the author may be able to add the fix to the next upgrade, and you can leave it at the last working version until the next upgrade is released.
The risks of not upgrading your WordPress website are quite high. The risks of upgrading don’t have to be. With preparation and testing, you should be able to upgrade regularly, without worrying and without taking much of your time.