Best Practices for Safe WordPress Updates on Big Revenue-Critical Websites

WordPress Updates

In my WordPress developer career, I’ve been asked many times about the best practices for safely updating WordPress core, plugins, and themes, especially when it comes to a site that can’t afford to have any downtime.

There are several update strategies to consider.  I’ll go over them here.  It’s really all up to the client’s risk tolerance vs. their willingness to pay for extra maintenance work.

But, with my WordPress update strategies, you should be able to perform updates the safe way without too much extra effort.

Could updating WordPress break my site?

Yes, it could.  But, it should be unlikely to break your site if you don’t have too many plugins or custom code.

Updating plugins could introduce a bug that a plugin developer pushed without properly testing first.  You are completely subject to the quality of the plugin developer, here.

If a bug happens, you can revert (which I’ll talk about below), but you do risk having downtime on the production site which might be costly if you are running a critical revenue-generating website.

So, you need a process to perform WordPress updates safely!  I’ll show you how.

Do I need to update WordPress?

Yes, for the love of God, yes!  You need to keep your WordPress up to date.

Many “production-critical” websites choose to delay updates for as long as possible out of fear that an update will break the website, resulting in loss of revenue.

What’s the long-term risk of not doing regular WordPress updates?  Not patching a known security vulnerability quickly enough could result in a hacker taking advantage of the exploit to compromise (hack) your website and web server.

Since WordPress is so popular, any published security updates are going to have vulnerabilities that are attempted against websites that are out of date.

If you can’t afford downtime from a bad plugin update, then you certainly can’t afford to get hacked!

What’s a good frequency for doing WordPress updates?

The more frequent, the better, but let’s be honest, doing daily updates is not feasible for most people.

When I was working for an agency, we did regular monthly updates for our mission-critical clients.

What’s the best WordPress update strategy?

I’ll give you two.  You either can do them on the production server with a testing process and rollback strategy in place, or you can do it off-site, test it, and then push it live.

Getting the production site versioned on a git repository is a huge help with both of these processes.  If you don’t already, you should consider getting your production site on git.

1) Live Updates with Testing and Rollback Strategy

This strategy is ok if you have a smaller website that gets less traffic, or has less plugins, or you just like living life on the edge!  Or, this strategy lends itself to being a lot more efficient for agencies that might have a lot of websites and want to use a central WordPress management system like ManageWP to take care of all WordPress updates from one place.

With this strategy, before you do any updates, use a backup plugin like Updraft Backups to do a database backup.  After the database backup is complete do a git commit using the Revisr plugin or the following command lines on the server…

git add .
git commit -m "Live changes before plugin updates"
git push

Then you have a commit in git storing a snapshot of all the files at that point along with a backup of the database in case that gets messed up for some reason.

Then do the updates on live.

After doing updates, test the site.  If there are issues that can’t be quickly resolved, you can rollback the files by running in the command lines…

git reset --hard HEAD

… or if that command gives any trouble for some reason, you can do the same thing with…

git checkout .

What about the database?

Usually rolling back files is all you need.  In only very rare cases, a plugin might affect the database after being updated, but normally, they require you to click a button to upgrade the database after a plugin update.

Typically, you won’t need to restore the database from the backup.  Rolling back the files should be enough to get the site back to how it was before the update.

2) Off-site Updates with Testing and Push

This method requires that you have another server (or perhaps a developer’s local environment) which has the site cloned from git with a semi-fresh database restored from the live backup.

Just apply all the plugin updates on this off-site clone of the site, test it there, and if all is good, then commit and push all the file changes with…

git add .
git commit -m "Plugin updates tested off-site"
git push

Depending on your git setup, getting those newly git-pushed updates can vary.

If your live site is just another clone of the repo which has an origin remote pointing to your git provider like GitHub, GitLab, or BitBucket, then you will need to run the following command line on the live server to pull down those updates…

git pull

However, if you set up your git so that the live site is the origin remote of your local clone, then the updates should be there on the live site immediate after pushing.

If you are needing to manually pull down the changes on the live site, I plan on writing a tutorial on setting up automatic CI/CD (Continuous Integration / Continuous Deployment), aka git deployment.  Let me know in the comments if you’re interested in that.

Which of these update strategies is better?

#1 is faster, but riskier in terms of possible minutes of downtime (time it might take to discover an issue).

Meanwhile, #2 will take a bit more effort just to maintain a clone of the site and having someone test there before pushing the updates.

I recommend #2 since it isn’t that much extra effort, and it is the safest way to apply updates when you’re working on a mission-critical or high-revenue-generating website.

How do I stop WordPress from auto-updating?

If you plan to adopt an update strategy like this, you might want to consider disabling automatic WordPress updates.

To disable automatic WordPress core updates, put this in your wp-config.php  file:

define( 'WP_AUTO_UPDATE_CORE', false );

To disable automatic WordPress plugin updates, put this in your theme’s functions.php  file:

add_filter( 'auto_update_plugin', '__return_false' );

To disable automatic WordPress theme updates, put this in your theme’s functions.php  file:

add_filter( 'auto_update_theme', '__return_false' );

Using the WP Rollback plugin

If you didn’t have one of these WordPress update strategies in place, you might be reading this because you already updated something that broke your site.

There is another option for you.  Use the WP Rollback plugin. It lets you select any plugin to rollback and lets you pick which version you want to roll it back to.

Comments or Questions?

Thanks for reading this.  I hope it was very helpful for you.

You might have a lot of questions because I probably breezed right by some things which really should be their own blog posts.  Let me know what questions you have, and I would be happy to answer them or write new posts to answer them.


Notify of

Inline Feedbacks
View all comments