How do you develop, test and deploy-to-live your Wordpress sites?

Its always a bit of a faff I find, especially where databases are concerned - mainly due to the fact that having a testing site needs a whole new database to be deployed which can sometimes be EXACTLY the same, except all the links are changed to the testing site url, instead of the live site.

Similarly any uploads that users have uploaded since the last time you needed to fix a bug or develop something new will have to be copied across to the testing site.

How do others do it? Do you just put up with the faff? Do you use clever version control systems which help?



There is a bit of personal philosophy that goes into a deployment workflow. It's not an easy question to answer outright without knowing your experience with servers and version control, your operating system, hosting, client's experience and tech culture, etc...

  1. Here's a similar question that has a lot of explanation.
  2. For content deployment, you can check out Crowd Favorite's RAMP plugin.
  3. WP Hackers is a great thread to find good information about deployments.

Personally, I make sure that I never hard code absolute URLs in my themes. Use bloginfo() or code relative URLs. I use a lot of conditionals in my wp-config.php file. Here's a vanilla version of my wp-config edits.

    case 'dev.yourdomain.com':
        $db_host = '';
        $db_pass = '';
        //define debugging
    case 'stage.yourdomain.com':
        $db_host = '';
        $db_pass = '';
    default: //Live
        $db_host = '';
        $db_pass = '';
define('DB_PASSWORD', $db_pass);
define('DB_HOST', $db_host);

//You could also set this as a variable above
define('WP_HOME', 'http://'.$_SERVER['SERVER_NAME']));
define('WP_SITEURL', 'http://'.$_SERVER['SERVER_NAME']));

I work on a lot of sites that follow the

  • local (personal hacking :) on my laptop web server) >
  • dev (testing on client server) >
  • stage (stable source for QA - content editing) >
  • production (live site)

Lastly, I would suggest you use a versioning tool to aid in your deployments such as GIT or SVN. It eases the process significantly and maintains source integrity between environments. Committing to your local is easily updated via command line on stage and production. It's best during discovery to define what version control you and the client are going to be using from the outset if they have developers working on the project. I personally use GIT for my version control. However, if a client uses SVN, I do a mix of the two on my local so I maintain a repo for myself while also committing to their repo.

We rarely have issues migrating from one environment to another. We do a find/replace in the DB to change the URL accordingly for embedded media, etc...

  • This is very useful! :) Thank you very much. So every time you deploy to each of the different servers do you duplicate the database from the live site? You say that you deploy to a staging server (stage.domain.com) for QA and content editing. What happens if the database changes while you're running the stage server on the live site? i.e. you or your client logs into stage and updates some content, but at the same time an contributor posts a new article on the live site? Do you just effect the content edits AGAIN on the live site? How do you tackle database structure changes? – Thomas Clayson Dec 15 '11 at 14:08
  • Sorry about all the questions! :p I'm very grateful for your time and help. – Thomas Clayson Dec 15 '11 at 14:08
  • On a new feature set, you can pull from prod > stage. Add the content for the new feature then, push back stage > prod. From there, stage is a high fidelity copy of prod and you can pull stage > dev. It's not often we pull the DB back from stage. The majority of exchanges with the DB happen from stage to prod unless a feature changes the db architecture. – Brian Fegter Dec 15 '11 at 14:55
  • If you want to use stage for content deployment and never touch prod, you can check out the RAMP plugin I posted earlier. – Brian Fegter Dec 15 '11 at 15:01
  • +1 everything above, with the proviso that some irritating plugins insist on storing URLs in serialised arrays, which can mess up moving things from one env's DB to another. The issue is that serialised arrays store string lengths, and are borken when the length changes. Thus, I'd recommend keeping the env's domain names the same if at all possible, e.g. dev.example.com, tst.example.com, www.example.com etc. – webaware Jan 9 '13 at 6:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.