How to Update WordPress Without all Hell Breaking Loose

I recently got into an interesting debate with one of my LinkedIn connections about whether or not we should keep WordPress sites up to date.  Good points were made, disagreements were expressed, and in the end, I think we left it as:

“It’s up to the developer to decide what updates are right for the client’s site and understand the risks associated should they choose not to update.

So long as the developer is not only aware of those risks, but can take responsibility for the consequences should there ever be any, and they make the client aware of the risks as well – then to each their own.”

Although we didn’t totally agree in the end, having this discussion with John ( Let’s pretend his name is John ) really got my thinking gears turning. John had one very good point. What about sites that haven’t been updated for several years and are still somehow functioning? Updating a site like that would surely unleash all manner of hell!

So I thought, hey, I should write about that, how to update WordPress without chaos ensuing! And it gives me an excuse to use a witty title – hurray!

Anyway, in cases like John’s, or just in general, what steps should be taken to ensure that as little hell as possible happens? How do you know how much or how little preparation you should be making? And if heaven forbid, bad things happen after your update, how do these steps help to either resolve the problem or revert the site?

And as an added bonus, if all hell breaks loose after a WordPress update, how can we troubleshoot and survive the catastrophe?! Gear up and let’s get started!

Real Quick, Why are We Updating Again?

Why should you keep WordPress up to date? Nick Edgar on 76design goes over not only why you should keep WordPress up to date, but also offers some prep steps that I may mirror here in my post. It’s definitely worth giving a look over if you’re not sure why updates should be bothered with in the first place.

Now that we’re clear on that, let’s talk about how we can take measures beforehand.

General Practices to Future-Proof

For developers on newly created sites, always started with the freshest version of WordPress. Check out the WordPress News to find out what it’s come with and familiarize yourself with code that may have become deprecated. Also introduce yourself to new functions that may have been released with the new version.

For existing sites that are fairly recent, say a version or two behind, you can usually risk waiting a bit for a version update.  If the newest release is a major one ( usually a 2 digit decimal like 3.8, 3.9, 4.0 and so on ), you may want to wait for the release that comes immediately after ( usually a 3 digit decimal like 4.0.1 ). I got this tip from Nick’s article that I mentioned earlier. To summarize what he said, the reason to wait for the release that comes after a major one is because with major releases, there are bound to be some new bugs discovered. So the 3 digit releases that follow will normally bring in patches for those bugs.

If this is an existing site that is several versions behind, and the newest release is bringing in security fixes like WordPress 4.0.1 is for older versions, definitely upgrade! That’s not a risk a developer or a client should be willing to take. However, don’t hit that update button just yet! If the site really is that far behind – there be dark stormy waters lurking beyond mate, waiting to sink ye prized ship down into the depths with the kraken!

 

Ahem – we’ll talk about that soon. Moving on.

For everyone, new and existing sites, no matter the version, background check plugins before you “plug and play”. It’s easy to forget that developers are human and WordPress is open source. Not all plugins in the WordPress repository are perfect, and even if they work alone, working in combination with all your other plugins might be a different story.

 

I generally tend to steer clear from anything that has the “hasn’t been updated in over 2 years” message ( shown above ). Pay attention to that sidebar. Check the version compatibility. I purposely click the negative reviews to see how old they are and if they might be relevant to me.

 

I also tend to be wary of plugins that don’t bother to fill in the information on their page very much. If the plugin author can’t be bothered to fill in a description or FAQ to ensure the plugin provides the smoothest experience for users, or can’t provide an alternate source of documentation, how available do I think this person is for support? Just some food for thought.

All right, so let’s get on with this update! How long is this going to take? Well, it depends…

When to Prepare for a Tussle and When to Prepare for War!

If a site is a version or two behind, and nothing much has really changed code-wise or plugin-wise, I doubt anything cataclysmic will happen with a version update. The same if you’re installing a new plugin that is compatible with your version, regularly maintained, and has decent reviews.

However, sharpen those battle axes if one or more of these are true:

• If the WordPress theme is custom to the client, especially if it uses third party libraries or plugins. ( Think slideshows, modals, masonry etc. )
• If there are several WordPress plugins, especially if they’re not up to date. There isn’t anything wrong with having lots of plugins, but you should be weary of their quality. Bob did an awesome update test on two different environments with 100 active plugins, definitely check it out.
• If the site is several WordPress versions behind.

If your axes are sharpened, then that means to update this site properly and minimize the worst that could happen, this is going to take some time. ( Better let your manager know if you have one. Explain that the extra precautions are necessary. Or if they still choose to charge into the murky depths, let them know you’ll be abandoning ship once the kraken shows itself! )

I can’t decide if I’m doing pirates or vikings or what kind of analogies I’m making here. But it’s fun? Anyway, moving on again to what steps to take before the doomed update.

The Steps BEFORE the Dreaded Update

Before you hit that scary “Update Now” button, read these first!

Step 1: Local Environments

If it’s possible to have an exact copy of the live site on your computer – do it. I’ve heard of people inheriting sites that they didn’t build and either don’t have access to files or don’t have the sufficient skill set to get on the live server with confidence. If there is a way to get the files from the server via FTP or you’re in touch with someone who can get that for you, along with a copy of the database, it’ll take some time, but it’s worth it all the way.

It’s always safer to tinker on your computer versus on a server.

If you’re not sure how to set up local environments, check out the famous 5-minute install as well as installing WordPress on your mac with MAMP ( Windows can use XAMPP or WAMP instead ). If you’re importing a database from a server into your local environment, check out changing the site url directly in the database.

Step 2: Backup & Version Control

Required!

• Backup a copy of the database. When WordPress updates it’s version, not only are core files affected, but the database has to update as well. So if something goes wrong, fixing it isn’t just a matter of just dropping the old core files back in. You’ll need the database that worked with your version of WordPress before you updated.
• Also grab a copy of your current version of WordPress from the release archive, especially if you’re many versions behind. This way reversing to your previous version is already a faster process with the clean files on hand.

Optional, but Better Safe than Sorry!

• It also might be a good investment to try VaultPress – a security and backup plugin. I haven’t tried it myself yet, but I hear it’s all the rave amongst the WordPress pros as well as the hosting provider I’m using.
• If you can set up version control with Git on your local WordPress site, that would be even better! I understand for those who aren’t comfortable with command line, this can be a time-consuming and advanced precaution. Give “Getting started with SourceTree, Git and Git flow” a read if you’re feeling adventurous.

Using version control or VaultPress are extra safety nets, but are optional if you make proper preparation. Backing up your database and grabbing a copy of your current WordPress version are the two precautions you shouldn’t skip – definitely take those steps every time before you update.

Step 3: Debug Power On!

This is where the local copy of your WordPress site comes in handy. In the wp-config.php file which is in the root of your WordPress site, turn the debugging on. Here is more info on WP_DEBUG and this is what it looks like in your config file when it is set to true:

/**
 * For developers: WordPress debugging mode.
 *
 * Change this to true to enable the display of notices during development.
 * It is strongly recommended that plugin and theme developers use WP_DEBUG
 * in their development environments.
 */
define('WP_DEBUG', true);

Turning this on will display any PHP errors on the front-end of your site, so it’s not advised to do this on a server where people other than you or the developer can see.

The Steps DURING the Dreaded Update

Step 1: Smaller Updates First

Once your database is backed up, and you’ve got a copy of the WordPress version before the update, start with small updates first. I normally update in this order:

Themes > Plugins > WordPress Version

First update the themes not in use, followed by the theme currently activated. Then update the plugins one by one. Yes I know, tedious! But it’ll be easier debugging for you. You can update all the plugins at the same time, but if you get the white screen of death, it’ll be harder to pinpoint which plugin or combination of plugins caused the problem. If any problems arise along the way, you can tend to them before the big version update.

Step 2: Finally Update the WordPress Version

Once deprecated code has been fixed, plugins are either updated or replaced with alternative plugins that work, and the themes are all up to date, you can finally click the scary “Update Now” button on your dashboard for the one-click update or manually update WordPress.

The Steps AFTER the Dreaded Update

Now, what if everything you tested was fine on local, but the live site broke! Or what if you just updated directly on the live server, and things broke. What should you do? Paniiiic! Krakens! Dragons! Pirates!

 

Okay, I’ll stop now. Seriously, if you’re in this situation, try not to panic. If this was tested locally or on a staging server before it went live and everything went fine, first think about what could be different on the live environment that would cause this. The best way to prevent WordPress from breaking is by making sure your local/staging copies are as close to the live version as possible. Still, we can only predict so much.

Quick! Abort! If reverting takes priority over resolving:

• Via FTP or version control, manually revert the WordPress site back to it’s previous version the same way you would manually update, except you’re replacing the files with that release archive you saved earlier? See? Told you those would be handy.
• Then re-import your backed up LIVE database on your live server. If you have multiple environments, you should back up multiple databases so you don’t have to go through all the url swapping.
• Refresh the site and make sure it’s back the way it should be.
• Also clear server cache if you are using any on live! Sometimes that ends up being the difference between the live environment and the local copies. If you’re using a caching plugin, refresh that as well.

OR Troubleshoot and Resolve:

I normally debug in the same order as I update. Check if the errors are being caused by the themes, by the plugins, or the version itself. Usually the severity of the problem is a huge clue at what could be wrong.

General Troubleshooting Steps:

1. Cache: Clear your browser cache, WordPress cache plugins, and server cache to confirm it’s not just cache trolling you.
2. JS Errors: Check your browser console for script errors.
3. PHP Errors: Check your server’s error log if you can and/or fire up that WP_DEBUG in your wp-config.php file for PHP errors.
4. Rule out the Theme: Activate a default WordPress theme and see if things work now. If it does, then the source of the problem is likely the theme you’re using. By default theme, I mean a theme that WordPress already has out of the box when you installed e.g. TwentyFourteen/Thirteen/Twelve and so on.
5. Rule out Plugins: De-activate plugins and re-activate one by one with WP_DEBUG on to catch any errors. If things break when a specific plugin activates, then that plugin is likely the source of the problem.
6. A Broken Dashboard: If it’s the dashboard that appears broken or unstyled, several things can cause this.
   1. The update didn’t complete. Make sure WordPress asks you to update your database. Try signing out of the admin and signing back in. It should prompt you to update the database before you sign back in. If this still doesn’t work, it’s possible that if you manually updated WordPress, you’re still missing some files. Trace your steps or re-update again until you’ve confirmed you’ve made all the necessary changes. It’s also possible that your WordPress version was so old, the upgrade went a bit wonky. You can manually check this url to make sure it prompts you to update the database if it never did:

      http://example.com/wordpress/wp-admin/upgrade.php

   2. Something wonky happened with the core files. Replace your wp-includes and wp-admin folder with clean files that you can grab from the release archive ( gotta love that place! ). So let’s say you updated from version 4.0 to 4.0.1. Have a copy of 4.0.1 handy so you can replace the wp-includes/admin folder.
   3. The database is corrupt. Rare, but it’s happened to me once before. That’s why it’s important to have your backups. If you discover that your database might be corrupted, revert back to your previous version of WordPress along with your backed up database, and seek assistance from a WordPress professional. If you are a WordPress professional, then someone other than you. 🙂 Two heads are better than one.

Usually the steps above will solve most WordPress issues as well as the “white screen of death”. For more common troubleshooting errors and how to resolve them, check out the Codex. Now what happens if the white screen of death has also killed access to your dashboard – oh no! Whiteness everywhere! It’s like a bad snow day!

If you can’t log into your admin, then de-activating a theme or plugin may seem like an impossible task. It isn’t though! Here are a few handy tricks that helped out someone else not too long ago:

Resolving the White Screen of Death without Dashboard Access:

1. Check your WordPress version before you replace core files. If you want to replace your wp-admin/includes folder, but don’t know what version of WordPress you’re using because you didn’t check beforehand and didn’t prepare a clean copy before hand, check the root WordPress folder for a README file. It will usually tell you what version of WordPress it is. Mine looks like this:

   <h1 id="logo">
   <a href="https://wordpress.org/"><img alt="WordPress" src="wp-admin/images/wordpress-logo.png" /></a>
   <br /> Version 4.0
   </h1>

   Once you know the version, grab the correct release from the release archive and proceed as usual.

2. De-activate a theme outside of the dashboard. You can do this by re-naming the theme folder that was currently activated before the site went white in wp-content/themes. WordPress will lose track of it and revert to a default theme. If your site comes back after this, then it is something in the activated theme causing the issue.
3. De-activate a plugin outside of the dashboard. This is done the same way as the theme. Re-name the plugin folder in wp-content/plugins and WordPress will lose track of it. If your site comes back after this, the plugin was the source of the problem. You can also use this trick if you have two plugins dependent on one another and you accidentally activated only one, and caused a PHP error because one plugin can’t find the other. This normally shouldn’t happen though with high quality plugins that have checks for dependents.

The Happy Ending

So the update has happened and either disaster has been avoided altogether or you braved through the storm and made it to the other side! Here’s what we went over:

1. What general practices can future-proof a site before an update.
2. How to predict ( somewhat ) how much preparation is needed before an update.
3. What steps should be taken before the update to prepare for the worst.
4. How to update step by step to minimize possible issues from arising.
5. And finally how to either revert the site or troubleshoot after the so-called update even if you don’t have dashboard access.

I hope this was enlightening and will encourage others not only to keep their WordPress sites up to date, but also to feel more empowered about it. Whether your site is only a version behind or an ancient dinosaur, making preparations beforehand and having a battle plan ready will help you to weather through the storm. Until next time – safe sailing my friends!