Every time you update WordPress, things can go fine or they can go drastically wrong. Here are some tips on how to update a WordPress site to help you avoid problems whenever you update WordPress.

How to Update a WordPress Website

1. Back up your site
2. Create a staging site and turn off any caching plugins.
3. Update one plugin on the staging site.
4. Test the staging site for problems.
5. If there are no problems, repeat steps 3-4 individually for the rest of the plugins. If there are problems, stop, troubleshoot, and fix them if possible.
6. Repeat steps 3-5 for the theme and again for the WordPress core software.
7. Make notes of what went wrong from the above steps.
8. Using your notes, make the same changes from steps 3-5 to the live site, leaving out the plugin or theme update(s) that caused problems.
9. Contact theme and plugin developers about the problems you encountered. For WordPress, check the support forums for known issues and log any new, genuine bugs by creating a ticket.
10. Update the core files last after updating plugins and themes (in that order).

Don’t Worry If You Forgot to Update WordPress

When was the last time you updated your WordPress plugins and themes? Or WordPress itself? If the answer is “a long time ago”, there’s no need to panic. You can easily update WordPress without breaking things.

Updating the plugins is a good idea, of course. Doing so ensures that you have the latest code for purposes of improving security, enhancing performance, and getting rid of bugs found in prior versions.

However, WordPress updates are something that a lot of website owners find to be uncomfortable at the very least and terrifying at the worst. And with good reason! If you update WordPress plugins, themes, and/or core files, and it breaks your site, you have to scramble to restore the prior version of the stuff you updated. Or, even worse, you have to restore your entire site from a backup!

You don’t have to feel anxiety over this necessary task. Just take a deep breath, get methodical, and dive in with the information presented below.

Why Not Simply Use WordPress Automatic Background Updates?

This tutorial is focused on how to update WordPress manually. However, Automattic introduced a new automatic background updating feature in version 3.7 of WordPress. It was meant to update WordPress automatically and thereby streamline and simplify the normally menial (and forgettable) chore of updating core, theme, and plugin files.

While that is helpful to a lot of users, it comes with an Achilles Heel problem. The weakness is that when you let the updates happen on their own, a human is usually not present to ensure that the update didn’t break something. For sites that earn revenue through ads or eCommerce, this can be a very bad thing. Especially if the site is down for hours or days before the problem is discovered.

Fortunately, there is a way to disable all updates, or just configure core updates, using the wp-config.php file or filters.

Best Practices for Updating WordPress Websites

The best practice for a manual WordPress update is to have a staging site. A staging site is an exact copy of your live site that sits on a different URL, such as “dev.yourdomain.com” or “staging.yourdomain.com” or “test.yourdomain.com”. Most web hosts will provide a pricing plan that includes some sort of staging site capability.

For example, our preferred hosting service, Pantheon.io, gives you not only a test environment but a development environment as well as multiple “mini-dev” environments for your team members to work on individually. This is an important feature at Pantheon because of how tightly Pantheon controls its WordPress, app server, web server, and operating system configurations for security and performance. Pantheon gives you the opportunity to test vigorously before going live. This is important because what works on a vast majority of WordPress hosts who haphazardly ignore security and performance for the convenience of their users may not work the same way on Pantheon. Pantheon has a “righteously opinionated” prioritization of security and performance over convenience.

Once you have a staging site set up, you can then do the updates. Do the core, theme, or plugin update on the staging site to see how things will behave, or if the site will break.

Do each update one at a time. For example, first, do the plugins one by one. Test the site after each plugin is updated, paying the most attention to the functionality that the plugin provides. Do that until each plugin is done. Then do the theme. Test the site. And then follow with the core WordPress update. Test the site again.

The reason you want to do all of this piece by piece is so that you don’t have to guess which of multiple simultaneously updated pieces broke the site if a problem occurs. Going one-by-one shows you that it was the change you just made that is most likely the culprit.

If the site doesn’t have any problems after the updates, you’re golden! Go ahead and do the update on the live site.

How Do I Update WordPress Core?

First of all, you’ll want to update the core software after you’ve successfully applied and individually tested the plugin and theme updates. This is due to plugin and theme authors tending to release updated code to stay ahead of WordPress core updates. If you do it the other way around, your plugins and theme may break.

How you update the core files depends on your hosting. Most hosting companies have an installer app to update WordPress in their hosting dashboards that either lets you auto-update core or gives you a button to do it. Or, you can simply run the update within your WordPress Dashboard.

Other hosts (the better ones, in my humble opinion), will apply a disciplined software versioning approach to all updates, including WordPress core. In other words, they’ll use a version control system (VCS) such as Git or SVN. Among other things, these VCS systems ensure that, if you need to you can roll back to a prior version of the software if something goes wrong. In those cases, you’ll want to use the VCS workflow the host provides rather than directly update WordPress in the Dashboard or in some kind of installer app. Pantheon.io is an example of one host that uses Git to control the deployment of core updates.

What to Do If An Update Breaks Your WordPress Site

If, however, the site does have problems, you’ll want to troubleshoot the issues before updating the live site.

Turn off all plugins and change to the default WordPress theme (it’s named after the most current year, such as “Twenty Twenty”). Now check to see if the problem is still occurring. Turn on plugins or themes one-by-one and test the problem again to see if it appears. If it does, you know that plugin or theme is likely to have caused the problem.

Make a note of the plugins or theme that caused the site problems and make sure that when updating the live site you don’t update those components.

Also, don’t add more plugins to the mix as you test and troubleshoot. If you do have to add more plugins as part of testing and troubleshooting, make sure that you remove them again.

Sometimes you have to wait for another release of the plugin for the problem to be resolved. And, it doesn’t hurt to contact the plugin developer and let them know there’s a problem. You can try using the WordPress support forums to ask others for help, and even submit new bugs to the WordPress development team at https://core.trac.wordpress.org/newticket

Why Does WordPress Break After Updates?

There’s a lot that can go wrong when you do a massive update after a long time of letting it go without patches. Below is an example of an update that happened to the WooCommerce plugin for eCommerce.

But first, to understand the magnitude and potential impact of software releases, you have to understand the numbering system.

Typically it consists of three numbers separated by decimals. They are: the major release number, the minor release number, and the point release number.

For the WooCommerce update we’re discussing, it was a significant release in that the minor release (second digit) and point release (third digit) in the release number increased by 1 and decreased to 0, respectively from 3.5.9 to 3.6.0. This was a quick indicator that pointed to a rather extensive list of changes (shown in the changelog below).

3.6.1 – 2019-04-18
Fix – Remove calls to ‘header_register_callback’ to prevent conflicts with some hosting providers and PHP versions.
3.6.0 – 2019-04-17
Enhancement – Merged WooCommerce Gutenberg Products Block feature plugin. Adds blocks for the new editor, including
hand picked products, featured products, products by category/attribute, sale products, new products, top rated
products, and best selling products. #22954
Enhancement – Only include order erasure bulk action if erasure is enabled in settings. #22354
Enhancement – Customer notes containing URLs now automatically converts to clickable links. #21927
Enhancement – Add increase and decrease stock options to bulk edit form. #22475
Enhancement – Allow states in zones to be searched by country name. #22339
Enhancement – Added registration success notices to account pages. #22650
Enhancement – Store notice is visible again if the notice text is changed. #22645
Enhancement – Add aria-label attribute to shop orderby selector to improve accessibility. #22683
Enhancement – When adding, editing, and deleting items manually from orders, the corresponding product stock will be
updated to reflect the event and an order note will log the event. #22329
Enhancement – Added suggestions for official extensions to Products, Edit Product and Orders screens.
Enhancement – Store attribute values as post_excerpt for variations to support easier searching for variations. #22083
Enhancement – Improved username generation and introduced wc_create_new_customer_username function. #23145
Enhancement – Allow opting out of Marketplace Suggestions 23218
Tweak – Generalize shipping estimate text on cart page. #22467
Tweak – Include auto draft orders in order list filters. #22380
Tweak – Only include the network orders widget on the main site dashboard. #22318
Tweak – Only show available shipping continents when selecting shipping zone region. #22131
Tweak – Use Shortcode block on default WooCommerce pages. #21817
Tweak – Show full category hierarchy in product URLs when term IDs are not sequential. #22526
Tweak – Make sure account and checkout endpoints only work under account and checkout pages. #22631
Tweak – Show loading graphic when order form is submitted. #22664
Tweak – Add alt text to gallery images #22863
Tweak – Improved display_name generation during checkout. #22786
Tweak – Send correct calling code and phone number to PayPal standard when using non-US addresses. #22693
Tweak – Added tooltip to refund-amount input box and made it readonly when taxes are enabled. #22820
Tweak – Remove admin alert for the WooCommerce Gutenberg Products Block feature plugin. #22982
Tweak – Setup Wizard: support keyboard navigation to toggle on/off features. #22936
Tweak – Set reply-to address for all emails. #22979
Tweak – Setup wizard redirection improvements. #22977
Tweak – Simplify display of discount amounts within orders. #22949
Tewak – Remove Marketplace Suggestions from product listing page. #23211
Template – Moved the order of rememberme checkboxes for accessibility so they tab in order. #21454
Template – New structure for attributes template, including new woocommerce_display_product_attributes filter. #22480
Template – Admin cancelled order email reworded. #22971
Dev – Update action scheduler to version 2.2.2. #23162
Dev – Update action scheduler to version 2.2.1. #23016
Dev – Use ActionScheduler for database updates. Improved update notice. #22904
Dev – Introduce woocommerce_reviews_title filter. #22216
Dev – Added woocommerce_cheque_process_payment_order_status filter allowing plugins to change the order status to the Cheque gateway. #21402

Well, that’s enough. There was much more, but you get the idea that many enhancements and tweaks occurred in the upgrade to WooCommerce 3.6.0.

Big releases like these are risky updates to make for a variety of reasons. The main problem is that it is difficult, if not impossible, to fully test each feature to ensure it will work on all websites. Developers will test their code on a variety of different systems and configurations, but the variability of potential conflicts with any number, combinations, and versions of plugins and themes written by third parties is impossible to fully know, let alone test universally. Such is the nature of free and open-source software (FOSS).

Therefore, when major releases drop, it is incumbent on each site owner to test their own site for problems when they update WordPress.

With the WooCommerce 3.6.0 release, many people (most of whom were panicked because they updated directly to their live sites and didn’t test first) complained that products wouldn’t display right, categories didn’t work correctly, and checkout flows broke.

The next release was a “point release” from 3.6.0 to 3.6.1. It consisted of a single fix, which was to remove a function call that caused conflicts with certain hosting providers and versions of PHP (the application server on which WordPress runs). The 3.6.1 release benefited many users but didn’t help all of them. Their particular situational fixes will come in future releases, or not at all, depending on what the root cause of the problem was for their particular install.

Summary

Be sure to test on a staging environment before going live when you do a WordPress website update. Test after every plugin, theme, or WordPress core change to ensure that the site is working properly after it has the latest WordPress update. It is always a good idea to use a code versioning system to keep track of code changes and be able to roll back to older code.

Related Article

5 Best Tips to Improve WooCommerce Security