It has happened to all of us at one point or another:
You click “update” on your live site’s plugins…and then the screen goes white. You did not touch any code; all you did was click one button! Way to go. You killed your WordPress website.
If it is that easy to break your website without touching code, you might be able to imagine how dangerous using the built-in editor on your theme or plugins, or editing code directly through FTP can be (and that you should avoid it at all costs).
Whether you are editing custom code on your site, or even just updating plugins, if you want to ensure everything is going to work properly, you must test everything in a staging or development version of your website first.
Here’s how to do it–and do it right:
The Easy Way
Most of the modern managed WordPress hosts out there today, like WPEngine, offer one click staging environments. From your WordPress dashboard or hosting account, you can simply click a button and they will auto-magically copy your live site and create a sandbox environment where you can test your code/updates without the fear of breaking anything too important.
Doing it Manually
Sometimes due to custom requirements, price or any number of reasons, using a managed WordPress host is not for you…and that means you (typically) do not have a single button to create stagings sites for you. The good news it is still not that hard!
At the lowest level, a staging site is nothing more than a copy of your current website. The most common route taken to create this copy of your live site is to setup a “staging” subdomain. For example, if we were to use Maintainn.com, we may want to use something like staging.maintainn.com (and don’t worry–our staging site is located elsewhere!). Depending on your host, the process to setup a subdomain may vary; what you ultimately want to achieve is to have a WordPress site available at that subdomain.
Now that WordPress is running, the fun comes in duplicating your site as it currently sits, which requires copying the files in your wp-content directory and then your database. The simplest (but maybe not the fastest) way to start this is to download a copy of your live site’s wp-content folder via FTP and then upload it again to your staging site’s wp-content folder. All your plugins, themes, and uploads will be copied doing this. There are faster methods if you are familiar with the command line and have those tools, and if you have those tools you probably already know how to do it!
The database is another thing all together. Unlike the wp-content folder, you cannot simply copy this over because of the links to the live site throughout your database. These need to be rewritten to point to your staging site, or you may run into issues.
A plugin we regularly use here at Maintainn (and WebDevStudios) is WP Migrate DB Pro, which, once installed (on both sites), will handle copying the database between sites as easy as it gets–simply the push of a button. While copying the database, it will also rewrite all your paths and URLs from one site to the other and make your life much easier. This is a premium plugin, which means it does have a cost associated with it ($90 for 12 installs), but take a moment to think how much time it will save you and decide if that time is worth the expense.
If that is not an option for you, though, another way to copy the database is to export your SQL file from one database and import it into the other, then manually fix your URLs.
I recommend using the Search Replace DB script by Interconnect. Download the file and place it at the root of your staging site. When you open it in your browser, it will auto-populate the database details from your wp-config.php file. Just follow the instructions in your browser to replace your live site’s URL with the staging site’s URL, and be sure to use the stable version and not the beta! I have never successfully used the beta without running into issues of some sort.
Once your wp-content directories and databases are synced up, you now have a functioning copy of your site! You can now login and test to your heart’s content. If something gets too out of whack, all you have to do is sync up your files and database again.
Secure your Staging Site
If your staging site is on a publicly available subdomain, you may want to secure it so that only registered users can access it. While there are a number of ways to do this, one of the easiest ways is installing a plugin like Password Protected; it will require a password to access the site. This will help keep the site away from prying eyes (and Google’s spiders).
Other Alternatives
I recommend putting your staging site be on the same server as your website that way the hosting environment is almost exactly the same. There are some cases where you may test code locally to find that it works, but it ends up breaking your live site anyway–and that is exactly what we want to avoid!
If you still do not want to setup a subdomain, you could also run a copy of your site on your local computer. A simple way is to use a free software such as AMPPS, which will make it extremely easy to run WordPress locally using their auto installer. Just install and follow your onscreen instructions for installing WordPress. Other options exist, but I recommend AMPPS because it works well AND supports Mac, Windows, and Linux.
Congratulations! You have a functioning staging site like a true professional.
Next time you go to upgrade that plugin on your site, try testing the updates on your staging site first to make sure everything works. While this is useful for everyone, it’s especially important for those who have sites that are integral to their income.
Now, as you’re playing around on the staging site, even if something does break, you will never again open a frantic support ticket because your website is down. Instead you will be cool, calm, and collected, and can find the solution at your leisure while all your friends rip their hair out with a downed website.
Nice post, thanks for the clear and concise description.
I have reasonable level of WordPress experience, although this is my first look at running a staging setup. However, I have run staging environments in other technology platforms.
Generally speaking, after there initial setup, staging environments have some different ongoing needs from Live environments: this boils down to a set of file-system files and database entries that need to remain in each separate environment, not transferred on an ongoing basis.
Two related questions:
1) Users & Security
Typically, it’s nice to have a bunch of test user accounts in a Staging environment to verify security-related features are functioning correctly, and it’s also good not to have the Live environment user account details in staging. You also mention securing staging so that it can only be accessed by registered users.
Questions:
a) when migrating on an ongoing basis from the Staging to the Live environment, how do you prevent test user accounts from being migrated to Live, or having the user-account entries in the Live system overwritten? Any plugins or techniques that help to keep account access settings separate?
b) Once you’ve setup Staging for registered-user access only, how do you prevent that same setting from being migrated across to Live in the next push of database and website files from Staging?
2) Independent Content
I’ve used staging environments where after initial setup, content is independent between Staging and Live. This enables new configurations and features to be tested well in Staging before Live release, but with no fear of the content used in those tests appearing when migrated.
Question: Is there a way to do this with WordPress: to have structure, features, layout and styling migrated between Staging and Live, without migrating content?
Thanks in advance!
Paul
I have 2 questions
I have an over customised old WP site and need to replace it as it will be too difficult to update.
I have set up a subdomain and can go ahread and install the latest wordpress and themes, plugins etc.
Question 1
Once it is all running as required what is the best way to then move it to replace the live / old wp site?
Question 2
What precautions should you take to protect the seo of the live site?