Step 1: Create the Virtual Host

When setting up a development environment, it’s almost always a good idea to use virtual hosts, because then you can easily host many separate test sites on the same machine. To do so:

• Find the apache directory on your computer. Mine was at /etc/apache2/.
• Open the httpd.conf file and find the following lines:

# Virtual hosts
Include /private/etc/apache2/extra/httpd-vhosts.conf

• Make sure the Include line is uncommented (make sure there’s no # at the beginning of the line
• Open the http-vhosts.conf file and add a virtual host. It should look something like this:

<VirtualHost *:80>
	ServerName your.virtual.host
	DocumentRoot "/your/files/location/"
</VirtualHost>

This setup basically means anyone connecting to your computer through port 80 (a web browser), looking for your.virtual.host, will see the files contained in the /your/files/location/ directory.

This is just the bare minimum for setting up a virtual host, and if you’re new to the concept you should probably explore the other options. There should be examples already in the virtual host configuration file for more info.

Step 2: Direct Your Computer to the Virtual Host

So you’ve set up the virtual host, but if you type your.virtual.host into your web browser, it will look for it directly on the web first. You need to tell the browser to go directly to your computer if your.virtual.host is specified. To do so, open up the hosts file, which is typically located in the /etc/ directory.

You should see some entries for localhost already. Add another which ties your virtual host to your local machine:

127.0.0.1    your.virtual.host

Step 3: Direct Other Computers to your Virtual Host

Now for any other networked computers, you just need to direct requests for your.virtual.host to your local computer. To do so for Unix based machines you can edit the /etc/hosts files as mentioned above. For Windows XP machines, the host file is located at C:\Windows\system32\drivers\etc\hosts.

The most difficult question to answer is, how do you know the IP address of your local computer on a network? Typically your computer will be assigned an IP address dynamically, so you’ll have to edit the hosts file every time the computer logs back on. To get the IP address, check your connection in the Network Preferences section. You could also try assigning a static IP address somewhere at the end of the available range, but this isn’t recommended because it could cause conflicts.

For Parallels though, the IP address of the Mac hosting the virtual machine is static, and can be found by viewing the “Parallels NAT” settings in the Network Preferences section. Throw that IP address in the hosts file along with the address of your virtual host, and you should be good to go!

The Development Environment

The production environment for the project runs on LAMP (Linux, Apache, MySQL and PHP), and uses WordPress for the blog / CMS duties. LAMP and WordPress are a snap to set up on OS X and Windows, so I won’t go into the details here. For Windows, you can even install a self-contained and self-installing package with all of the technologies, like XAMPP. If you need help, check google for current instructions.

Synching the Files

In the initial stages of development, it’s common to a multitude of changes throughout the site, and as such it can be inefficient to use simple FTP for pushing changes live. I was looking for an easy way to instantly sync the development and production servers, and I wasn’t worried about version control or multiple developers have access to the same code. If I was, I could have used Subversion, but that seemed a little too much for this simple task.

So instead, I used rsync over SSH:

rsync -rve ssh [mylocaldirectory]  [myuser]@[myserver]:[myremotedirectory] --exclude-from=[exclude-file]

… and stored the command in a file named update-files.sh so I could execute it whenever I needed to. You’ll have to enter your SSH password when you run it, but it’s considerably more secure this way. Some notes on the command:

• -r makes it recursive (obviously need that)
• -v makes it verbose (helpful)
• -e allows you to include a remote shell
• --exclude-from allows you to specify an exclude file with patterns to ignore in the transfer. This is helpful because you can exclude domain specific configuration files, .DS_Store files, etc. Just make a separate file, and include filenames / patterns to ignore one to each line.

That’s it! In this example you’ll need remote shell access via ssh, which may be difficult to obtain if you run on a shared host. If you run into problems you can use rsh or run a rsync server… check the rsync man page for more details.

You’ll also need access to a Unix / Linux command line, which isn’t a problem for Mac users. For Windows users, get Cygwin.

Synching the Database

Given the nature of WordPress, to maintain a similar copy of the database across domains would basically require:

• Backing up the database to be moved
• Copying the database backup to the other domain
• Restoring the database backup on the other domain
• Replacing the domain specific mentions in the WordPress DB

Fortunately, all this is easily scripted. I used two files, first, on my local (development) machine, I created a file named update-db.sh:

mysqldump -u [db_user] -p [db_password] [db_name] > current.sql
ftp ftp://[username]:[password]@[remote_domain] <<**
cd updater
put current.sql
exit
**
ssh [username]@[domain] 'updater/update-my-db.sh'

Breaking it down:

mysqldump -u [db_user] -p [db_password] [db_name] > current.sql

Dumps the current development database to a .sql file.

ftp ftp://[username]:[password]@[remote_domain] <<**
cd updater
put current.sql
exit
**

Connects via ftp, moves into the updater directory and transfers the sql backup.

ssh [username]@[domain] 'updater/update-my-db.sh'

Connects via ssh to the remote shell, and executes update-my-db.sh, which should look like this:

mysql --user=[db_user] --password=[db_password] [db] < ~/updater/current.sql;
mysql -e "UPDATE wp_options SET option_value = '[live domain]' WHERE option_name = 'home'" --user=[db_user] --password=[db_password] [db]
mysql -e "UPDATE wp_options SET option_value = '[live domain + path to wordpress' WHERE option_name = 'siteurl'" --user=[db_user] --password=[db_password] [db]
mysql -e "UPDATE wp_posts SET guid = REPLACE (guid,'[local domain]','[live domain]')" --user=[db_user] --password=[db_password] [db]
exit

This file needs to be on the remote machine so it can interact with mysql. Basically, it takes the domain-specific mentions and changes them to point to the live server instead of the development one.

And that's it! Just run update-db.sh on your development machine and any WordPress changes (posts, pages, options, etc.) should be replicated on the live server.