WordPress Question: How Can You Create an Easy Staging Environment?

Our WordPress Q&A Session continues! We’re asking you folk to send in your questions about WordPress, and we’re handing out free memberships at WPMU DEV for your troubles. Check out the details here.

Today’s question is about creating a staging environment for WordPress development, and comes to us from a member of the WPMU community named Matt.

What’s the easiest way to create a How to set up a staging environment for WordPressstable staging server, in parallel to the production server, when building a WordPress site? And what sort of system or tool would I need to push from staging to live, with as little fuss as possible?


Calling all you hardcore WordPress developers out there. Can you offer Matt any advice on this matter? If you’ve got a suggestion or something to share, please leave a comment below this article and let us know.

Have you submitted a WordPress question yet? If not, get cracking! You could win a 3 month membership at WPMU DEV – that’s $159 worth of WordPress awesomeness, yours for free!

Here are some of our previous WordPress questions, sent in by WPMU readers. If you can offer an answer, please leave a comment on the articles and share your thoughts with the community.

Image: Under Construction Sign from Bigstockphoto.

13 Responses

  • WPMU DEV Initiate

    I usually set up a second sub domain at dev.mydomain.com and use .htaccess / .htpasswd techniques to prevent eavesdroppers.
    To ensure the live content will work, I use the current export tools available in WordPress.
    Unfortunately, WordPress does not have a method of exporting themes and plugins along with the database (although images and users can be exported).
    Either way, It does help with development when you work with a pre-existing site (WordPress Multisite would seem like a good candidate for this… but any error in your coding could actually bring the whole lot down).

  • I haven’t got the magical answer but I’ve been researching this a little and in the planning stages of coming up with a deployment setup to streamline my workflow.

    For creating a staging environment I’m currently using Vagrant (http://www.vagrantup.com). From within my local project directory I can run the “vagrant up” command which will install a virtual instance of Debian Linux (same as on my live server), install/configure Apache, mySQL and the basic WordPress install all within 1.5 minutes while I make a cupa. So a clean dev environment just for that project. I can remove that virtual instance just as easy by typing the command “vagrant destroy” in the projects local folder (on the command line).

    Deploying your code back to the live/staging environment is the trickier bit that I’m still trying to figure out.

    I think THE killer deployment setup will include Vagrant, Git and something like Opscode Chef to tie all of this together.

  • Flash Drive

    I was a Fantastico guy for a long time, but these days, nothing beats a multisite installation paired with a BackupBuddy license.

    Since September, BuckupBuddy has fully supported multisite in ways that no other plugin can attest: http://pluginbuddy.com/5-reasons-to-love-backupbuddy-with-new-wordpress-multisite-support/ .

    You can do full multisite backups, import stand-alone sites into your multisite installation, and best of all, export any site right out of multisite–ready to installed on a client’s server.

    Couple these features with multisite’s network wide plugin, theme management and two second site creation, and I think we have a winner.

    I love this setup and I think it gets better every day. It actually makes me excited to test new themes and deploy staging sites.

  • I had this very problem for the last couple of years. I have a license of backup buddy when updating WordPress itself of making adjustment to the them files.

    But for straight up content, you have to check out RAMP. It allows your authors to work on content and ‘promote’ or as they say ‘create a batch’ and move the content from your staging environment to your production site. It is quite simply amazing.


    Check it out, you will love it.

  • Design Lord, Child of Thor

    I’m of the opinion production databases should not be shared with stage, test or development areas.

    What I do is create a full backup of the current site using Backup Buddy and restore that site with a new database at stage.mydomain.com or whatever. Then I have an exact duplicate of the production site.

    If there is no new content after I’m done, it’s easy, just restore the stage site to production using Backup Buddy. Of course, you may have had a few posts and comments or even hundreds since the duplicate site was created in stage, and that can get tricky.

    Just think … the new design is all in the new template files so that can just be copied over, but remember some of the image sizes for home page thumbnails (or where ever) most likely have changed, so you’ll need to create new images for old posts.

    Heck, the new site may even use new plugins.

    Always a challenge.

  • I still use the same old method as Deadpan110 with the subdomain on my testing area I like to call “WordPress Lochness”.

    One of our developes uses the backup buddy method, and he swears by it, but I noticed sometimes there are some small errors, and I just feel safer exporting it the old school way through the sql database. Call it a warm and fuzzy safety blanket, but it works for us, and we have it down to a science ! :)

  • I use a sub domain for testing, demo.wpsites.net and backup my main site using cPanel as its the fastest way to restore files and databases

  • The code and the database are two different things. Keep code in source control like Git or Svn. Make a dump of your production database to run locally. Set up you local environment to use Apache, MySql, and PHP.

    The trick is the Domain name and URLs which are.sometimes stored in the database. But in most cases, the wp-config.php setting for Site_url is enough to let you run locally with a domain like dev.example.com.

    I follow a pattern from Rails for data schema changes – write a migration script that applies the change (e.g. add table, add columns, create indexes, even add data for lists) and test them locally. When they are solid, commit them to source control, along with you tested code.

    To deploy (to staging, or production) first pull from source control, and when needed run the migration script. This works great in teams, and documents in source control all of the changes both to code and data schema.

    The key is to accept that your production database is king. Don’t make changes to a local copy that you push back up to production. What if someone added a comment? What if you have more user entered content? Instead, see data schema (DDL) changes as “code” and let your other code handle the processes that add, update, delete and show your data (DML).

Comments are closed.