Subscribe via

Creating a Staging WordPress Blog for Testing

Over the past few months, I’ve been meaning to create a staging WordPress blog that is an exact replica of my production OMNINOGGIN blog so I can test major feature changes before releasing them to my production site.  I have to admit that there are many other interesting things to spend time on (see also: Make Popularity Contest Work with WP-Super-Cache and NowThen Photo Display WordPress Plugin) so I have been lagging at getting this task done.  Fortunately the WordPress 2.5 released was enough to motivate me to get this done.  My goal in this post is to provide a step-by-step set of instructions (or checklist) for getting this task done.  I run Apache 2.2.8, MySQL 5.0.51a, and PHP 5.2.5 on a FreeBSD 7.0 machine that I have complete control over.  Keep in mind that these steps will vary depending on how your blog is configured.  It is a good checklist nonetheless so without further ado:

  1. Create a new virtual host in your web server’s configuration file.  Call it something like  Using apache as an example, you can add the following lines into your /usr/local/etc/apache22/httpd.conf:

    <VirtualHost *:80>
      DocumentRoot /usr/local/www/apache22/data/YOUR-WEBROOT_staging
      ErrorLog /var/log/httpd-error-YOUR-DOMAIN_staging.log
      CustomLog /var/log/httpd-access-YOUR-DOMAIN_staging.log combined

    Then gracefully restart your apache by running:

    /usr/local/etc/rc.d/apache22 reload
  2. If you are hosted with a provider that has users a dynamic IP address, add this new to your DNS update software.  For ddclient (and ZoneEdit service) add the following to your /usr/local/etc/ddclient.conf:,\

    Note that the commas and backslashes have to be exactly placed as shown on the first 4 lines.

  3. Duplicate the WordPress database by running the following commands:
    On command line:


    Notice that there is no space between the -p flag and your password.
    In MySQL:

    create database YOUR-WORDPRESS-DB_staging;
    grant all on YOUR-WORDPRESS-DB_staging.* to 'your-mysql-username'@'localhost';
    grant all on YOUR-WORDPRESS-DB_staging.* to 'your-mysql-username'@'%';

    On command line:


    The –opt flag will take care of all the necessary table locking/unlocking in addition to a number of other great things for you.

  4. Change the “siteurl” and “home” options in the newly copied database. If this is not done, your staging site will always redirect you to your production site.
    On comand line:


    In MySQL:

    update wp_options set option_value='' where option_name in ('siteurl', 'home');
  5. Set your privacy to private so your staging site is not visible to the world.
    In MySQL:

    UPDATE wp_options SET option_value=0 WHERE option_name = 'blog_public';
  6. Duplicate the WordPress code by running the following commands:

    rsync -aP --delete --exclude="DIR1" --exclude="DIR2" YOUR-WEBROOT YOUR-WEBROOT_staging

    This will perform a one way synchronization from production files to staging files with the exception of “DIR1” and “DIR2” directories (use this as needed). Extraneous files are deleted on the staging side.

  7. Create a .htpasswd file by running the following command:
    htpasswd -bcm .htpasswd YOUR-USERNAME YOUR-PASSWORD

    Move this file to a safe place (not in your WEBROOT_staging directory). We will be using this in the next step.

  8. Create a .htaccess file under YOUR-WEBROOT_staging and add the following into it to password protect your staging site.
    AuthName "Section Name"
    AuthType Basic
    AuthUserFile FULL-PATH-TO-YOUR-.htpasswd-FILE
    Require valid-user

    Make a copy of this file and put it in a safe place (not in your WEBROOT_staging directory) as we may reuse this in the future.

  9. Change the database used in WEBROOT_staging/wp-config.php by replacing:
    define('DB_NAME', 'YOUR-DATABASE-NAME');


    define('DB_NAME', 'YOUR-DATABASE-NAME_staging');
  10. Make sure you disconnect your staging site from the rest of the world.  Disable all plugins that generate sitemaps as these tend to report site changes to the search engine too.  Disable all statistics plugins/javascripts that share the same counter database as your production site (A good example of this is Google Analytics & chCounter).  You might have more of these kind of plugins in your blog so do another review of your plugins and theme.
  11. Unless you want to test caching, I would disable plugins like WP-Super-Cache and WP-Cache also (makes development a lot easier).
  12. I like to change the color of the Blog background and Admin background to something ridiculous so I can easily tell the difference between the staging and product site.  You may modify the background of the admin interface by editing /wp-admin/css/colors-fresh (or colors-classic, depending on which one you are using).

Phew!  I didn’t think it would be this extensive when I first imagined making a staging WordPress site.  The good news is that once you’ve done it, you can skip many steps if you are planning to do a production -> staging clone.  All you have to do is convert steps 3-6 into a script, and also have it copy your previously saved .htaccess file into your WEBROOT_staging after the rsync.  You can include steps 9-12 into the automation script with a bit of ingenuity.  I will post my script to do this synchronization once I write one up.

Here is the script I use to automatically clone my production blog to a staging blog. After running the script, all I do is go into wp-admin and disable all the “linking to the outside world” plugins. Hope this helps!

Have I covered all the basis? Do you have a better way at doing this? Please share your ideas in the comment form below.

8 Responses to “Creating a Staging WordPress Blog for Testing”

[go to last comment]
  1. Artem Russakovskii

    I finally got around to setting up a staging site and was looking for the list of things we discussed earlier. Excellent instructions, I will be using them to double check I got everything covered and automate the setup.

  2. Dan Moore

    This is great. But how do you move code/content/etc from staging to production?

  3. Artem Russakovskii

    Dan, manually. You would want to double check merging every file so you don't overwrite anything by accident. I use Beyond Compare and compare the 2 dirs (awesome Windows app, the Linux drive is mounted via samba).

    Have a look here:

    Dan, manually. You would want to double check merging every file so you don't overwrite anything by accident. I use Beyond Compare and compare the 2 dirs (awesome Windows app, the Linux drive is mounted via samba).

    Have a look here:… for a list of comparison tools.

  4. Will

    Ty- thanks a lot. I was able to follow your post to create a development site for my wordpress site. However, some of the pages redirect to the main page instead of the dev. site. I ran the – "update wp_options set option_value='' where option_name" while logged in to my new database. Is that the right thing to do?
    I am clueless at this point.

  5. Ty Bone

    Hi Will,

    You're welcome! This is probably because there are some hardcoded links in either your theme or your posts. It's probably easy to fix the theme. For the posts, you will need to write a script to go through your posts table to replace to Hope that help!

  6. Alec Hanson


    Fantastic. That has been such a great help as I had previously tried and got to the issue with the siteURL in the staging DB, thanks for the SQL code and for covering all this so clearly.

    Very much appreciated.

  7. justdoproperty

    Oh also not only is this great for creating a staging area but also if you need to move your wordpress installation from one server to a new server.

[go to first comment]

Leave a Reply