Keeping Track of wp-config.php Information Across Different Environments

Using GIT (or other version control systems) to keep track of and deploy WordPress sites is becoming the “in” thing. Do your changes, commit them to the repository and, in some cases, watch them automatically go to another server in your environment. It’s a great workflow that allows you to always have the option to back out of any changes made and revisit what you did later.

What I see most people do though is just use a single GIT branch (I’m going to stick to GIT for the rest of this). Sure this still works but what happens if you accidentally overwrite your wp-config.php file somewhere? Either you’re going to overwrite it across your whole system or you’re going to lose those changes later as they’re not in the repository with you.

There is a better way to do this.

note: I realize keeping wp-config.php in a public repository such as GitHub is idiotic for security reasons. If you’re going to do this get a private repository at somewhere like Bitbucket or, better yet, roll your own.

Now that I’ve got the security disclaimer out of the way a better way to manage your sites is one GIT branch per server. On this site, where I don’t have a staging server, this means that I have the master branch where the production version of my site lives and a dev branch that I use to develop with on my local machine. On other projects I’ll often add a staging branch as well as that’s typically what I would use to show clients and others who need to see it before launch.

So if you’re just using a single branch go ahead and create at least one other to develop in. Once your site is branched now you need to worry about the configuration files.

Now in each branch create an appropriate [branch-name]-config.php file. In addition, edit that branches .gitignore file to exclude any config files from the other branches to prevent you from accidentally saving the file to the wrong server.

Example:

If I have 3 branches, master, dev and staging I would do the following for each branch

  1. in master create the file master-config.php in the same folder as wp-config.php.
    edit .gitignore and add staging-config.php and dev-config.php to it
  2. in staging create the file staging-config.php in the same folder as wp-config.php.
    edit .gitignore and add master-config.php and dev-config.php to it
  3. in dev create the file dev-config.php in the same folder as wp-config.php.
    edit .gitignore and add staging-config.php and master-config.php to it

Once the files are are created we’re going to take out all the information before /* That’s all, stop editing! Happy blogging. */ in wp-config.php and add it to each of the created files as appropriate. In other words for the wp-config on the production server add its information to master-config.php, for dev add it to dev-config.php, etc.

At this point if you push all your changes each server would have a custom configuration file based on the branch and a broken wp-config.php. We’ll now need to tell it which one it needs to use. The code below, added to wp-config.php in every branch, will take care of that for you.

// Load the correct configuration.
if ( file_exists( dirname(__FILE__) . '/master-config.php' ) ) {

  @require_once( dirname(__FILE__) . '/master-config.php' );

} elseif ( file_exists( dirname(__FILE__) . '/staging-config.php' ) ) {

  @require_once( dirname(__FILE__) . '/staging-config.php' );

} else {

  @require_once(dirname(__FILE__) . '/dev-config.php');

}

/* That's all, stop editing! Happy blogging. */
/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') ) {
  define('ABSPATH', dirname(__FILE__) . '/');
}

/** Sets up WordPress vars and included files. */
require_once(ABSPATH . 'wp-settings.php');

Notice the end of the file it has the same information as the normal wp-config.php file. Before that however we start with our production server and check for the master-config.php file. If it is there use it, and if not try for staging and then default to local.

This is a solid setup that will make sure that even if you put an extra configuration file on your production server it will still use the one it is supposed to. In addition, you can make your changes anywhere and not have to worry about what the configuration is. Finally, and one of the handiest things for me, it helps me make sure I’m not coding directly to the wrong branch when I’m working as, with the wrong configuration, the site simply won’t work on that server.

Of course to use this you need to keep your site in GIT or another version control system but if you haven’t taken that leap yet look at it as just one more way to make your life easier when you do.

5 Replies to “Keeping Track of wp-config.php Information Across Different Environments”

  1. Thanks for this! I’m in the process of getting a workflow going with Git, similar to this, and I was looking for a solution to dealing with the config file. We are going to do Local -> Dev -> Production, since we have a lot of clients that we do continued work with after the sites have launched.

  2. You’re welcome. I had the same problem when I was getting into my GIT workflow, such a seemingly simple problem otherwise. Good luck and let us know any pitfalls or improvements you find.

  3. Hey Chris thanks a lot for this, that’S a very interesting point of view on the WordPress development workflow.

    What do you do for databases ? I use to just copy and use a script to change the “base_url” in every table … do you have a better solution for that ?

    Thanks

    1. For databases I use Navicat (http://www.navicat.com) to physically copy them between servers and then I use https://github.com/interconnectit/Search-Replace-DB to change the domain name. The latter will replace it across the entire database, not just the two options.

      There are definitely far more efficient ways to do this these days, particularly if you do it a lot (I’m not currently doing client work currently so I don’t have to do so all that often). That said, I’m really curious about some of the newer methods such as Migrate DB Pro which seem much more elegant.

      1. Thanks for the answer, that’s interesting for Migrate DB Pro, I’ll have a look at that ๐Ÿ™‚ I only have a few client in WordPress, but that’s always a mess to sync between dev and prod … I try to improve and perfect my workflow to avoid losing time !