If you’ve been active on the various Divi and WordPress community groups over the past few weeks, you’ve probably seen quite a bit of activity surrounding the recent WordPress 4.5 update, Divi and other broken sites. Andrew even updated an existing article about it this morning.

The fact of the matter is this: if you are using an open source CMS and any collection of third party free or premium themes or plugins, the risk of breaking your websites is high. This risk increases for every piece of functionality you have added to your site.

Now, as the old saying goes ‘You can’t make an omelette without breaking a few eggs.’ This is especially true of products like WordPress and Divi. With all the amazing new features that are coming to both products, it’s impossible to expect each and every release to be pixel perfect, especially if you consider the size of some of these changes and the vast variety of users who use them.

So how do you prevent an upgrade from breaking your site, or your client’s site?

Back it up before you @#$* it up.

I had to censor that word, so I’ve leave it up to you to choose your expletive of choice, but the principle is too important to sugar coat it. Before you upgrade ANY site, make a backup. If you read the WordPress upgrade notifications (how many of you actually do that?) you will see that even WordPress suggest that you backup your files and your database before any upgrade.

Suggested tools:

1. Good old FTP and PHPMyadmin
2. WP Migrate DB Pro
3. Backupbuddy
4. Updraft Plus

Development -> Staging -> Production.

Never, ever, EVER upgrade a live site if you haven’t already tested the upgrade somewhere else. If you are a web developer, designer, builder or doing anything for a client that involves their website, you must have all three of the above environments in place.

Your development environment is your local machine, PC, laptop, Mac, whatever you are using. There are a variety of easy to install local development environment apps that allow you to set your computer up to act like a web server. Not only does it make creating your websites quicker, but when the time comes to upgrade, you can upgrade your local copy first.

Your staging environment is a place where you have a full copy of the live site, but under another URL. It could be a subdomain (website.url.com) or a sub folder (url.com/website/) or whatever. Ideally it should be on the same server is the live site, so that the server environment is the same. Either way it is a place where a) you can upload new functionality for the client to review before going live and b) most importantly you can test an upgrade. That’s right, even after you have tested an upgrade on your local environment, test it on the staging one first. Any number of things could be different from local to staging.

Suggested tools (local development):

1. MAMP (Mac OS)
2. WAMP, XAMP (Windows OS)

Check your themes and plugins.

Whenever a new version of WordPress is being beta tested, plugin and theme developers have the opportunity to test their products against the new version. The next time WordPress prompts you to upgrade, take a look at your plugins (either from the WordPress.org site or the plugin developer site) and see if they are compatible with the new version. If they are not, it may be a good idea to wait until they are to upgrade.

Also always use plugins or themes that are regularly updated by their developers. For 4.5, Elegant Themes released an update the day that WordPress was updated. Some plugins or themes are created by their developers and then abandoned. My rule of thumb is that if a plugin hasn’t been updated since the last minor WordPress update or a theme since the last major WordPress update, I don’t use that plugin or theme.

Customisations are bad, mkay.

I’m going to say this loud and in public. If you have ever paid for a developer to add functionality to your site, and they did this by adding custom PHP to either your functions.php or your theme files, you are going to have issues. Who knows how the WordPress core, your chosen theme or plugins could change over time, causing code conflicts with this custom PHP. If you ever have to pay for a customisation, it should either be done in your child theme or as a plugin. In fact, unless the customisation is layout specific (ie changes to your theme) then it should be added via a plugin. That way you can easily disable that plugin when you upgrade.

I’ve been working with WordPress for going on 7 years now and I’ve never (repeat NEVER) had a live site break because of an upgrade. I’ve broken plenty of local or staging sites, but never a live one. By following these four simple principles I can almost guarantee that you will do the same.