As a website manager for more than 20 WordPress installations, I’ve become familiar with the quality assurance (QA) testing, backup, update and check out process for the WordPress core application and the more than 25 plugins I use. If you’re managing your own WordPress installation, these tips should help you in the future.
First things first. WordPress makes it very simple – almost too simple – to upgrade the core application, plugins and even themes via your site’s administration panel. You can’t miss the indicators informing you the core, theme or one of your plugins have an update available. Once you see those indicators, you should absolutely resist the temptation to check off that box and hit the update button in your production environment.
You ask why? Well, take a look at any WordPress support forum and you’ll see a recent thread starting with the following phrase … “I updated [insert plugin name here] and my site blew up”. This happens to almost every WordPress installation at some point, and in many cases the site administrator has not prepared in advance for this issue. More complex themes built on their own framework, and eCommerce plugins have made upgrade issues even more prevalent.
The problem could be a plugin conflict, a theme framework conflict or something else that is not easy to identify after the fact. Sure, you could just ignore those updates, but your site could then be open to a security exploit that will eventually make things even worse and more difficult to solve.
So, what to do?
Prior to hitting that upgrade button, you need to implement a backup strategy for your database, WordPress core installation, plugins, themes, theme framework, and your media library and uploaded files. Of course, there are plugins available to help you with this process. You thought your Web host took care of backups for you? Hardly. Almost all Web hosts – including Spider Creations – only make backups for use after a catastrophic server meltdown. Their backups – our backups – will not help you in a situation where you need to restore your site to your portion of the server.
Your backup strategy must include storing recoverable assets at a different location, preferably with a different host. Don’t just back up on your server, and don’t just keep a backup locally. Look to store backups with a different provider to ensure redundancy.
The next step missed by many is quality testing your backups on a regular basis. Yes, files can be corrupted occasionally, and if you need to restore from to a previous backup, you may issues if that backup file – or part of the file – is corrupted. On a regular basis I do restore full sites to a development environment that is unavailable to the public. This can be on your local computer or on a sub-domain like dev.yourwebsite.com.
Once you have your backup strategy in place, you’re prepared to update the WordPress core application and plugins. With a recent full backup in place and saved where you can access it, go ahead and upgrade your core and plugins – one at a time – and check out the site as you go along. If anything happens and you are unable to solve the problem quickly by deactivating a plugin or renaming the plugin’s folder name, you’ll be able to restore from a backup.
Once restored, you can move to the process of figuring out what went wrong with the upgrade. Again, if you update one at a time and check your site’s functionality along the way, you should be able to narrow the problem down to a specific plugin, and figure out what to do next.