Responsibly Updating your WordPress Website

Recently, the WordPress Core CMS was updated to version 4.6. It’s not a particularly feature-heavy release, but it adds additional stability and security to WordPress. If you are the kind of person who gets spooked by the idea of updating your WordPress version, then this article is for you.

This article is intended to help you understand a bit about what WordPress updates are, how they relate to Plugin and Theme updates, and, most importantly, how to update your WordPress sites without causing havoc.

Some Background on WordPress Core Updates

The Open Source WordPress project is potentially one of the largest and most global open source projects. It has the most international contributors of any open source project in existence. Thousands of people have contributed to the code, and new contributors from around the world are added every new release.

Some people wonder why they have to update their WordPress Core so often. In reality, it’s typically only 3-4 times a year. Furthermore, the improvements in the code are real. Actual bugs are resolved, improved coding standards are implemented, and important security features are applied. Basically, when you see a new update notification, you can think “Oh wow! New free code that people all over the world helped create to make my website better!”

Perhaps, in the past, you’ve updated your website and had nothing but trouble. This happens to many WordPress users. It’s generally not because of the WordPress project itself but instead due to third-party plugins and/or themes.

Basically, if you only built your site with the Core features of WordPress, and used only the default themes that WordPress is shipped with, then you could update your website every time without any fear of any negative impact.

WordPress Core contributors follow a consistent methodology. They continually test Core against itself. This is called “backward compatibility” and it’s one of the most important features of WordPress, one that sets it apart from all other CMS’s. Backward compatibility ensures that every WordPress version will be able to be updated without losing any of its Core features or content.

What this means: When you have trouble with your WordPress updates, it isn’t because of Core, it’s because of the third-party plugins and/or themes that you are using on your website.

Full disclosure: I’m a plugin author and I love third-party plugins and themes. They really do make the whole WordPress experience far more full-featured. Furthermore, when I say plugins or themes are the problem, it’s not ALL plugins and themes. It’s important to understand that every plugin you add to your site cannot be tested with every other plugin on your site. It’s literally impossible for developers to know all the nuances of every possible plugin that you might be using. That said, the majority of well-supported and well-developed plugins and themes would not cause you any trouble whatsoever. For example, Bob Dunn at BobWP.com posted his experience in updating 100+ plugins with the WordPress 4.0 update. He didn’t encounter one problem.

Most likely, you’re saying to yourself: “Who just uses WordPress Core without plugins or themes?”

You’re right. No one does that who has a professional website. Even my own personal site is a custom theme and uses roughly 15 plugins. So how do we responsibly update our WordPress website considering all the plugins and themes that we all rely on?

The Preferred Procedure

While there are several methods to update reliably (some of which I highlight below), the preferred procedure, which I recommend, is as follows:

• Backup your database and your wp-content folder;
• Deactivate all plugins;
• Update all plugins and themes;
• Update WordPress Core;
• Re-activate each plugin one at a time and look for errors to troubleshoot;
• Once all plugins are re-activated (or left deactivated because of bugs), you’re all done.

Unfortunately, it’s not an ideal method. Doing all of that on your live site really leaves your site looking bad for a while. So how do you do all of that without giving your live visitors a bad experience?

The following is a progressive list of four general methods for updating your website reliably. If done right, plugins and themes won’t cause you any trouble at all.

The Bare Minimum Method (BMM)

This method relies on the following tools:

• Being able to back up your site either through your host or a plugin like BackupBuddy;
• And having either a live development site, which is a copy of your live site, or a local environment like Desktop Server, Pressmatic, MAMP, Xampp or the like.

Here’s the basic concept. Simply push all of your updates in your development environment first and troubleshoot any issues there. Then, once you know how well your theme and plugins support the new version, do the whole update process live.

The first step in this method (and, virtually, all the methods) is creating an exact duplicate of your site either locally or on a live development environment. I personally recommend that every WordPress user start learning about development environments by using Desktop Server. It’s a great tool for working on your site on your local desktop or laptop and learning about the process of pushing sites live as well.

The easiest way to duplicate your site using Desktop Server is to install a plugin called “Duplicator”. Duplicator does exactly what it sounds like: It duplicates your website. It will provide you with a ZIP Archive of your WordPress install, including the database.

Desktop Server works exceptionally well with Duplicator Archive ZIPs. Use Desktop Server’s “Import” tool to duplicate your site locally. Read their full tutorial on that here.

The other option is having a live development site. Most users who prefer live development sites typically install them as sub-domains of their site, like dev.example.com. Duplicator can be useful for duplicating your site to a sub-domain if you are familiar with creating a new MySQL database and importing the database from the Duplicator archive file. Otherwise, I recommend simply uploading your whole site via FTP and using Migrate DB Pro to import the database. Lynda.com has a great tutorial on that here.

Once you have your site duplicated either locally or on a sub-domain, run all your updates there. Take notes on any potential problems or plugins that can’t be updated and then simply run your updates live.

Pros and Cons of the BMM

The major benefit of this method is that you don’t have to have the knowledge and skills to be able to push your development environment to your live site. I call this the “Bare Minimum Method” because it’s the minimum steps I think every single WordPress user should be taking. It’s just a step above “cowboy coding” − meaning coding on your live site where any minor problems will be live for all your visitors to see.

The unfortunate downside is that you are essentially doing the work twice. The second time you do the updates, though, you’ll be able to fly through it a bit faster because you’ll know exactly which plugins you can’t update or any other tweaks you found in your development update process.

The other downside to this method is that while all your files and database are duplicated, your server environment isn’t exactly identical. For example, Desktop Server might be using a different PHP version that you do, or you have HTTPS on your live site but not on your sub-domain. These details can make it look like all is well locally, but when you do the updates on your live site, you run into problems that you can’t replicate in your development environments.

The One-Click Staging Method

This method is only available to users whose web host provides this functionality for them. For example, Media Temple has a one-click staging method available in their Managed WordPress Hosting. This allows you to click a button that says, “Push to Staging”. Your host then creates a duplicate of your website, including the database, to a custom staging url.

Once that’s done, you can do all your updates as needed. Rather than taking notes and having to do it all over again, you can use the tool to now “Push Staging to Live”. For those who don’t want to mess with local development environments and pushing databases, live staging tools are magic gold dust from heaven. If your hosting provider doesn’t have a staging tool, then you might want to think of migrating to one that does.

The biggest benefit of this method is that you only have to do your updates once. Secondly, you don’t have to know anything about migrations. These are valuable for almost any user.

However, the biggest con to this method is that it doesn’t support “versioning”. Basically, just like your plugins have version numbers, imagine your website having a version number. Why would you want that? Well, in order to keep track of when certain changes were made and being able to roll back and forth to any version of your website. This is definitely a more advanced subject, but nonetheless important because of how it improves the whole process greatly.

Which brings us to our last method.

The Local to Repository to Live Method

Think of your most complex website. Perhaps you created a custom theme or highly complex child theme. Maybe you have a custom functionality plugin that extends the features of the website and your plugins. With so many moving parts, it’s hard to have a really good overview of all the things that get changed when you run WordPress updates.

This method is designed to give you granular control of everything that has changed on your website. There are a wide variety of approaches to this method that includes using management scripts like Composer or Git sub-modules. Developers love to get “creative” here.

Boiling it down, it involves using a repository like Github (or Bitbucket or Beanstalk) to commit code changes in order to have a continual snapshot of all your website files. Then, when everything is versioned correctly, you push that to a live staging site for review. Upon approval, you push that live.

Database changes are typically pushed directly to staging, but can also be versioned through the repository (though many developers I know find that a bit unnecessary). More advanced database tools like Navicat are usually preferred for this type of work.

This is the method most professional developers use, particularly for large corporate websites or e-commerce sites where pushing buggy code live is simply not an option at all.

Pros and Cons of this Method

The largest positive of this method is having granular control over all of your code. With that control, you can push any amount of small or large changes. You can also revert back to a previous state with relative ease.

Here’s the negative: You virtually have to have an advanced degree to have the skills and know-how to make this happen smoothly. Having been thrown in the deep end several times, I have experienced this myself, but there are much more knowledgeable users who can tell you all the intricacies of this method far better than I can.

Go Ye and Update WordPress Without Fear

The bottom line is that updating WordPress can result in your site not working correctly because of third-party plugins or themes. Updating WordPress away from your live site is necessary. Whether you use a one-click method or the full local-versioned-staging-to-live method, it’s important to do it right, not just to avoid stress but to keep your website visitors from having a negative experience of your live site.