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