Making WordPress Development a Little Easier

Absolute URLs

It’s a common problem, made more difficult if you choose to develop locally. But, whether we like it or not, WordPress depends on abolute URLs to generate links to different pages around your site, to resources such as Javascript and CSS and to media files included in pages. This is fine if you’re working in one location, but this is rarely the case.

Development environments differ between developers and agencies, but will usually consist of some or all of the following:

1. Local Development Environment
2. Test Environment
3. Staging Environment
4. Live Website

Personally I develop locally, set up a staging area to test the website on the live hosting – using a SymLink to temporarily redirect the user to a holding page or copy of the old website – and then redirect the symlink to the live website. At work we develop straight to a test/staging environment then copy this over to new folder once finished. We also have several sites setup with SVN deployment.

Making Life a Little Easier

The best way around this problem that I have found in other platforms is the Zend Framework’s XML configuration files. They allow you to define a “Production” environment then extend this environment with other settings configurations. One website I have worked on included the production or live environment, a test site environment, a local environment, a development environment set up by a freelancer who had worked on the site and, unfortunately, a developer’s home environment.

A similar setup can be achieved in WordPress by defining configuration variables based on the web address the site is being accessed by. Here is an example of how you might achieve this, making use of PHP’s “$_SERVER['SERVER_NAME']” variable:

$siteFolder = 'martindownton';
if ( $_SERVER['SERVER_NAME'] == 'localhost' ) {
	define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '/' . $siteFolder);
	define('WP_HOME', 'http://' . $_SERVER['SERVER_NAME'] . '/' . $siteFolder);
	define('DB_NAME', 'testdatabase');
	define('DB_USER', 'testusername');
	define('DB_PASSWORD', 'testpassword');
	define('DB_HOST', '12.34.56.78');
} else {
	define('WP_SITEURL', 'http://' . $_SERVER['SERVER_NAME'] . '');
	define('WP_HOME', 'http://' . $_SERVER['SERVER_NAME'] . '');
	define('DB_NAME', 'livedatabase');
	define('DB_USER', 'liveusername');
	define('DB_PASSWORD', 'livepassword');
	define('DB_HOST', 'localhost');
}

This code will add the site folder onto the host, allowing me to work on “http://localhost/martindownton/” but will not add this once the site goes live. It also changes the database credentials, allowing me to work on two different databases.

If you want to work on the same database there is a great plugin called “Search & Replace” that can be used to replace any URLs generated in your database.

An Alternative?

As with all things technical, there are more than ways of achieving the same outcome. Another solution I have used in the past is to take advantage of the “Hosts” file, a file within Windows which redirects URLs to a different IP address. You can set up “martindownton.eu” to point to 127.0.0.1 so that any URLs generated are the same on your test site as on your live site. This has an obvious drawback in that you will have to keep changing it to view each environment, but perhaps it is slightly easier to implement than the previous option.

#postaweek2011 3/52