1. Keith Davis

    Sounds impressive Sarah

    “Work Seamlessly Between Development, Staging, and Production Sites” is perhaps the “Philosopher’s stone” of WordPress.

    I’ll have to read this one a couple of times to understand the details.


  2. ThachPham

    First we will copy database to all enviroments?
    Sorry for about dumb question but I’m new. .(


  3. David Egan

    Thanks for the article – will definitely check this out.

    The WP CLI tool has a very handy “deploy” plugin that migrates the database…for those comfortable with the command line.


  4. Cédric

    Hi @Sarah !
    Thanks about that. How can we manage de DB problem on a dev/staging/production environment ? Let’s say my client create contents on the production site and we are developing some features on the dev -> staging part. How can we merge these databases ? Have you got some articles or ressources for this problem when working on multiple environment ?

    Thanks a lot !


  5. Simon R Jones

    hi ThachPham, this solution takes care of different config settings on your local and live websites, and a staging test site if you have one. It doesn’t take care of the database itself, however.

    I use it for things like database login details, debug mode, anything that you want to be different between your local test site and your live one. It also takes care of the site URL in the WordPress database so you don’t need to hack that in the database when going live.

    You’re quite right, you need to copy your database from local to your live environment too. I usually work on a local copy of the site while building a site so when I’m ready to review this on staging or live I’ll just copy the DB up to the live website (via SQL dumps). If you have database connection settings correctly setup in the multi-environment config it should then just work.

    Maybe there’s a need for easy database synching too! But I think there are a few solutions out there already like WP Migrate DB https://wordpress.org/plugins/wp-migrate-db/


    • jacobperl

      WP Migrate DB (or the Pro version) does not merge databases. It simply overwrites the targeted tables with the source tables. It is very elegant and works well for what it does. One really handy thing it does is to automatically replace URLs as needed from one environment to the other.
      But it does not solve what seems to be the Holy Grail of multi-environment collaborative WP development…which at least for me is the biggest pain point of multi-environment developing.

      This multi config file thing looks very clever and should at least help with part of the pain anyway! Thanks!


  6. Rob Blake (@treb0r)

    Something similar but superior (IMHO) has already been implemented for WordPress by the roots guys as part of their Bedrock project. Their approach is much simpler and uses environment variables stored in .env files. When combined with Capistrano deploys, it works like a charm.



    • antjanus

      Genesis Skeleton for WordPress is also a good alternative. I find it sharing many aspects of Roots.io. The main advantage that I see with GSW is that it doesn’t alter WP’s folder structure. It has the whole package of multi-environment work, along with utilities that will copy DBs for you and even do backups (something Roots still has on their to-do list on Bedrock).



  7. Spanka

    Very sweet post Sarah – thanks! Looks like its time to revisit the mysql via git thing again :)


  8. Simon R Jones

    Thanks Rob and David – some great links to WP tools there I’ll check out :)


  9. Paul

    I just do this with a simple IF / SWITCH statement, checking the server name then changing the constant’s for each of the environments http://www.paulund.co.uk/multi-environment-wordpress-wp-config-php


  10. Russell Heimlich

    I can’t wrap my head around which problem this solves. The wp-config.php file should be unique for each site. You shouldn’t be managing it under version control. And why do I need the database credentials for the live site on your testing server? Or your local development machine? If I break into your testing server then I would also have the necessary credentials for your live server now.

    If you really want to have some settings keep them in a separate file in the root of your WordPress install and include it in wp-config.php and then version control that file.

    Pro tip: If you need to enable WP_DEBUG temporarily you can set-up a simple conditional in wp-config.php

    if( isset($_GET['xyz']) ) {
    define('WP_DEBUG', true);

    Then just add ?xyz to the end of a URL to show error messages. Handy when you have a problem on the live server and want to see what the error message is.


    • James Grumish

      This is attempting to solve a problem when it is not feasible to have multiple versions of the same file — e.g. a repository structure. The goal is to make the entire codebase server-agnostic, which is not an easy thing to do.


  11. Simon R Jones

    Russell Heimlich – I disagree, it is useful to keep configuration in version control so when different people work on a project things can be up and running easily. If someone can break into a test server, they can break into a live server. Most config settings aren’t unique between a test and live version of a site, except perhaps database and debug settings.

    Also, I wouldn’t advocate adding a GET param to enable debug mode since is a security risk in live environment. Security through obscurity isn’t a great approach.

    Paul – the if/switch approach is what we used to use, though I prefer the organisation of splitting this out into multiple files. Makes things a bit more transparent and easier to manage. But there are lots of ways of achieving the same aim :)


  12. Robbie

    This is a very nice solution. Does this method also supports a WordPress multisite setup?


  13. Paul Gerhard

    This is not working if lime we you do not use the host file and instead use different folders in htdocs for the development environment. I am using for instance localhost/nameofsite for my development environment and I get a ‘error establishing a connection to database’. Anything that can be done for this particular case?


  14. Mike Louviere

    This is nice but it only tackles the easy part of multi-environment WP configurations. If you build a site and launch it live and then get a change request from the client, you either have to do a content freeze on the live site and work on dev->staging and deploy to Live post QA OR you have to tackle the challenge of merging your new dev work into the live DB. That is the REAL issue we need a solution for in the world of WP development. RAMP is the only solution that I’ve found which comes close.


  15. Ricardo Quintas (@ricquintas)

    Interesting discussion. As freelance developer I have years of experience using corporate CMS’s based on SAP, and would never imagine a scenario without different environments.
    Minimum is always 3. Dev, Test and Prod. But I’ve been with customers where 4 or more is the norm.
    The lack of any sort of support on this area when using WordPress (or any othe open source CMS for that matter) is something that really frightens me. Not only from a maintenance perspective, but also when you’re trying new stuff, were you’re often forced to try that in Production.

    That is why I find the idea of Flat File CMS’s (like Kirby http://getkirby.com/ for example) a very interesting alternative (at least when it comes to solve this developers dilemma).

    I’m not comparing which type of CMS is better, or want to dive into the DB or no DB debate.

    But the fact that replicating an environment (content included) happens in a snap, makes me consider very seriously the Flat File CMS option.

    Any thoughts on this ?



Comments are closed.

%d bloggers like this: