19 Comments


  1. 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.

    Reply

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

    Reply

    1. Yeah this solution basically just handles the config aspect of it, doesn’t take care of migrating databases – you’ll still have to do that.

      Reply

      1. 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 ?

        Reply

  3. 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.

    Reply

  4. 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 !

    Reply

  5. 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/

    Reply

    1. 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!

      Reply

  6. 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.

    http://roots.io/wordpress-stack/

    Reply
    1. 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).

      https://github.com/genesis/wordpress

      Reply

      1. Nice link. There’s a lot of things to learn with GSW. Looks like more complicated than the wp-config.php setup, but interesting to check it out.

        Reply
  7. Spanka

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

    Reply

  8. 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

    <?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.

    Reply

    1. 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.

      Reply

  9. 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 :)

    Reply
  10. Robbie

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

    Reply

Leave a Reply