If you are developing WordPress sites, themes or plugins, you probably know that setting up a local development environment can speed things up immensely. The easiest way is to use XAMPP or MAMP. I prefer XAMPP by the way as it is available on Windows, Mac OSX and Linux.  Installing XAMPP gets you most of the way to headache free WordPress development, the rest is setting up your local server/virtual servers so that it as closely mirrors your remote set-up as possible.

However, some settings like blog address are held in the database which makes mirroring local development and remote production servers a little tricky. If you just backed up the database on the remote set-up and imported it to your local XAMPP server through phpMyAdmin then WordPress will still think that it is at http://www.wordpressblog.com and not http://localhost

Permalinks might not work, plugins might break and so on.

What you need to do is either edit the database, searching and replacing the relevant fields or edit the wp-config.php file to override the database settings. I don’t recommend the first option as it is error-prone and you have to do it again if you throw the database in the opposite direction.

Editing the wp-config.php file is relatively easy, just add the lines

	define('WP_SITEURL', "http://localhost");
	define('WP_HOME', "http://localhost");

but if you edit the wp-config.php file you will have two different versions of the file.  This will cause your site to break if you absent-mindedly uploaded your local wp-config.php to the remote server.  If you are using source control, like git or svn, and forget to exclude the file the same thing happens.  Plus you have to maintain two versions.

Here’s what I do. I set-up the wp-config.php to check to see if it is a local server, if it is then set the configuration one way, otherwise set it using the production values.

The first 3 settings are the same whether local or remote.  In some cases the MySQL hostname will be different, so just set it later with the others.

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'wordpressdb');

/** MySQL database username */
define('DB_USER', 'wpdbuser');

/** MySQL hostname */
define('DB_HOST', 'localhost');

We’ve moved the 4th setting, the password, because it is different. And we will add the ‘WP_SITEURL’ and ‘WP_HOME’ settings later to override the database values. But first two more settings that are the same whether local or remote.

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Ok, now the fun starts. These five lines checks to see if the server’s address is 127.0.0.1 If it is, we assume it is a local machine and set a WP_ENV to development, otherwise we set it to production.

if ($_SERVER['REMOTE_ADDR']=='127.0.0.1') {
	define('WP_ENV', 'development');
} else {
	define('WP_ENV', 'production');
}

Having determined whether the environment is local or remote, we then grab the site address for use with ‘WP_SITEURL’ and ‘WP_HOME’.  I don’t hardcode it in as it gives me the flexibility to re-use it for any virtual server.

$debian_server  = preg_replace ('/:.*/',"", $_SERVER['HTTP_HOST']); $_SERVER['HTTP_HOST']);

Finally in these lines, if it is the local development, we set a simple dummy password and disable post revisions. We also set WP_DEBUG to false, this allows us to set it to true if we come across any tricky problems.

If it is the real production server then we set the password to its original value which should be a long and random set of characters.

if ( WP_ENV == 'development' ) {
	define('DB_PASSWORD', 'short_dummy_password');

	define ('WP_POST_REVISIONS', false);
	define ('WP_DEBUG', false);

	define('WP_SITEURL', "http://$debian_server");
	define('WP_HOME', "http://$debian_server");
} elseif ( WP_ENV == 'production' ) {
	define('DB_PASSWORD', 'the_real_password_which_is_a_very_long_and_random_string');
}

This wp-config.php file is now safe to be used on the remote production server or on your local development server.

One note, we didn’t set the WP_SITEURL and WP_HOME on the production server instead using the values in the database.  But if we moved a site from one domain to another we could do so.

If you have any questions, feel free to ask me in the comments.

Related posts:

1. How to fix WordPress automatic upgrades and plugin installs on XAMPP If you’ve ever had problems with WordPress automatic updates...
2. [JRuby on Rails on GAE/J] how-to put rubygems into a jar file to get around file limitations GAE (Google App Engine) has a limit number to the...
3. How To Use Email To Create And Reply To Forums on Redmine We’re using Redmine not only as a BTS (Bug Tracking...
4. Localizing dates in WordPress themes Our theme on the English side and the Japanese side...

Related posts brought to you by Yet Another Related Posts Plugin.

Tags: development, local, remote, tip, virtual servers, wordpress, wp-config, xampp
This entry was posted on January 28th, 2010 at 2:41 pm and is filed under techtips. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.