Different database connections in WordPress development environments

Advertisement:

Since I am using version control with GIT, I have set up different environments for my current WordPress/Magento-married project. For this project, I did not want to continue “cowboy coding”, so I set up a remote staging / testing / development site and multiple local development sites. Each site has its own purpose and needs its own MySQL database. So I had to handle different database connections in my WordPress installations. Well, I could work with only one DB, but …

!This post is seriously aged.The world has moved on and the stuff described in this post might be outdated. Having trouble getting this to work? Leave a comment and I'll have a look into that.
This post is a loose English translation of my German blog post Mehrere WordPress Entwicklungsumgebungen mit unterschiedlichen Konfigurationseinstellungen nutzen, originally published in r.o.b.’s kellerclub (yes, that’s me). To view the German original, follow this link to the second page of this article.

Since I do not want to screw up the “origin” database of the live site, I created multiple copies at some point in time and used those. Each site has its own database and its own database users and passwords. I used multiple copies of the wp-config.php to handle those different database connections and copied the file I needed for the current envinronment. I did not want to ignore the configuration files in version-control, since the TYPO3 Pharma-Hack has made me sensitive to especially watching config-files and to not using the same login-data across multiple installations. But after using GIT for a while and switching branches etc, I got sick of always copying the configuration files with the corresponding MySQL logins.

When I was new to git, I tried to ignore the .gitignore file itself and added the wp-config.php in each WordPress development environment indivudally. This way, I could use different database connections for each WordPress environment that I am developing with. It turned out, that it wasn’t a good approach, because somehow the wp-config.php-file was ignored on the live site – possibly I was doing something wrong.

Recently, I accidentally found a blog post on how to use a local configuration in each WordPress development environment (or guessed the right Google keywords ;-).

How to set up and use different database connections for copies of the same WordPress installationy

Mark Jaquith describes the elegant idea of including another PHP-file with WordPress’ database configuration-information. If that file was not found, a “standard” MySQL-database connection would be used. In his post he also introduced the idea of plugins that have to be turned off (forcibly!) when in a local developing environment.

The code for handling a different database connection for each WordPress development environment

1
2
3
4
5
6
7
8
9
if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {
  include( dirname( __FILE__ ) . '/local-config.php' );
  define( 'WP_LOCAL_DEV', true ); // later more about that
} else {
  define( 'DB_NAME',     'production_db'       );
  define( 'DB_USER',     'production_user'     );
  define( 'DB_PASSWORD', 'production_password' );
  define( 'DB_HOST',     'production_db_host'  );
}

This little snippet in the wp-config.php is really smart. As said, it tries to include a file named local-config.php – if it is not found, then it uses the following database configuration. So basically all you need to do now is create a local-config.php that resides in the same folder as your wp-config.php and define the database connection for the current environment just as you would define them in your real wp-config.php. Add that file to your .gitignore and you’re done!

Deactivating plugins on developing sites

There are some plugins that you might not want to use on a development site. Maybe they don’t make sense in a developing environment, or they’re slowing down your site or whatever. One kind of plugin are all the WordPress caching-plugins that are out there. There’s no use for them on a dev site, if they’re not even counterproductive. On my blogs, I am using the WordPress Backup to Dropbox plugin – which has no good use on a dev site either. Actually, it is oerwriting my live-site backup with data from the dev sites – which I do not intend. So that’s another plugin to deactivate on developing environments.

With defining the constant WP_LOCAL_DEV and setting it to true and the help of the small, lightweight plugin by Mark Jaquith, you can prevent specific plugins from being activated on your development environments. So every time you have a local-config.php, the specified plugins won’t be loaded.

Advertisement:

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>