At the General WordPress Meetup this month we discussed staging WordPress. Here are a few notes from the meeting and some helpful links. As always, I hope to see you all next month as we learn about PHP and WordPress!
What is a staging environment?
A staging environment is a place to experiment, play, and test with WordPress. You can use this space to test your current (or future) site and content, without messing anything up!
What do we mean by “staging”? Staging a website is breaking down the development of the site into separate stages. It is a one possible tier in the product development process. The end stage is often called your “production” environment. The actual site visitors see when they visit your site. Commonly if you are developing software of any kind (WordPress sites are software!) you will have multiple environments that precede your production site. In larger organizations, or with more complex sites, you may have multiple staging environments, for security, quality assurance, customer feedback (like a beta environment) and more.
For the purpose of a single-operator site like most folks you should have at least a single staging environment.
What the heck do you mean by “environment”? An environment is a place where code runs. This includes the operating system, software your code is dependent on, and any configuration specific to each (memory allocation, disk quotas, etc).
It’s a fancy way of saying the space where you’re running WordPress separate from where your production site is running – so you can change and modify one environment without impacting another.
Why are they important?
WordPress sites are complex. Even your basic sites has many moving parts. As Carl Sagan once said, “If you wish to make an apple pie from scratch, you must first invent the universe.”
Setting up a separate staging environment allows you to test, play, and work in parallel with your production site without breaking anything. Staging sites also offer a level of redundancy when it comes times for updates to themes, plugins, and WordPress itself. Are you worried that an update might break something? Or that a theme change could reset your customizations? Better to test that on the stating environment than your production site!
How do you set up a staging environment?
There are generally two ways – locally, or on a web server somewhere. There are pros and cons of each. Bother are generally the same in how WordPress will function.
Local setups are best handled by a software that will set up the environment for you. One of the most popular solutions is a fee software called MAMP, which is available for both Macs and Windows PCs.
MAMP is easy to set up. Install the software and hit the “Start Servers” button. You now have a web server running on your computer. From here you can install WordPress, setup a MySQL database, and get to work customizing WordPress.
– Easy to set up with many guides available online
– Offline access meaning other’s can accidentally see your in-progress site
– Have to muck with command line make it appear as online site with a nice URL
– Can’t easily show others as the site only exists on your computer
– Local MAMP environment can be different from actual production site (this is more rare now a-days, but still possible).
Web server (subdomains)
Another way to set up a staging environment is to use a web server like you have for your production site. But Chris, I only have one web server – where my current site lives! Ah ha! This is where subdomains come into play. Most web hosts (GoDaddy, Bluehost, Dreamhost, etc.) allow you to set up a secondary subdomain. This is a separate site that runs on your existing web host (most likely in a separate folder from where your current site lives).
So, for your staging site you might have something like “test.coolsite.com” and your production site will live at “cool site.com”. You can work on test.coolsite.come and not touch your life site’s configuration. For many hosts setting up subdomains is easily handled through your administration panel. You create the subdomain, access the directory (folder) where the subdomain lives, and install WordPress like you did for your production site. Here are a few guides for some of the more popular web hosts.
– Often runs on the same exact configuration as your production site
– You can share the subdomain with other people so they can see the site while you are working on it.
– A little more difficult to set up, but if you already have a production site, it’s a bit more of a “rinse and repeat” procedure as you’ve already done it once!
– It is another live site on the Internet! You have to make sure security and access are managed (along with updates).
– If running on a subdomain: Make sure your staging site is kept up to date!
– Set the site to “Discourage search engines”. In WordPress, under “Settings>Reading” look for the option and enable.
– You may even want to use a plugin to password protect the site.
– If you really want to make sure search engines don’t inadvertently suck in your in-progress staging site, add a text file to your root subdomain directory and insert the following two lines of text.
This tells search engines to not index anything in the subdomain.
So once you have your site setup as you want it in your staging environment, how do you move it to production? In the past you would have to have done this manually. Which, as the Codex explains, can easily be a time-consuming and error prone process. If this was 5-7 years ago I would recommend the manual process (and still think it’s important to understand what is happening underneath the hood) but today there are many helpful, well-written plugins that can help make these migrations much easier.
I recommend two plugins to help, each is a little different in their approach. These are well-supported and well-reviewed plugins with many tutorials and guides available online. Pick one and follow the directions to move your staging site to production. As with anything WordPress related, make sure you have a backup of your files and database before doing anything!