If you’ve set up a local web server on which to develop and test your web applications, it’s likely that you’ll want to run more than one project or application on it at any one time, as different people in your office produce work for different clients, or as clients require maintenance or updates to their web sites.
(Setting up Virtual Hosts is also used very commonly to allow one web server to host multiple websites. So, many of the Apache steps in this article are also applicable for production servers. However, this article is aimed at people developing using something such as XAMPP.)
It doesn’t matter if this is a dedicated machine local to your network or if it’s set up as the localhost on the actual machine you use – either way it can be very useful to set up a different virtual host for each project to keep them separate from each other and help them to mimmick better the behaviour they’ll display when they go live.
What do I mean? Take, for instance a setup where you’re working on two web sites, both being run from the same development server. You might access these in your web browser by typing the following two addresses:
Or, you may choose to use DNS in which case you may access them with a slightly nicer-looking address:
Both of these approaches generally work fine, afterall who cares what the web address looks like when you’re just developing the application? However, both of these approaches can have potential problems if you want to use absolute rather than relative paths in your site (either in hyperlinks in you HTML or for paths within your PHP programming).
For instance, if you have a menu structure which appears on all pages, you need it to work if called from www.mysite.com/subdir/anothersubdir as well as if it’s called from just www.mysite.com – when the site’s live you can easily just code your links like this:
… however that won’t work quite as expected when it’s being viewed on your development server.
With a virtual host on your web server, your two (or more) web sites can be accessed like this in your web browser’s address bar:
Notice how, despite both being on the same machine and same Apache installation, I can call them as if they’re totally unrelated and the web site will act as if “firstwebsite” is in fact “mysite.com” or whatever your final web address for the site will be.
There are a host of other reasons as to why you might want to set up a Virtual Host on your Apache development server, and I’m guessing that since you’ve arrived at this article you already have one of those reasons. So, rather than spelling them all out I’m just going to show you how to do it:
Step 1: Edit your Apache httpd-vhosts.conf file
The location of this file will vary depending on your setup. If you’re using XAMPP (which is a popular, quick ‘n’ easy way to get a functioning Apache environment set up on your Windows machine) then the file is usually stored in this directory:
To tell Apache to treat requests containing “firstwebsite” as a request for that web site, you need to make the following changes to the conf file:
Step 1a: Tell Apache that you want to use name-based virtual hosting
Look for the following section of the file, and remove the # symbol to uncomment the “NameVirtualHost” line:
Step 1b: Add Virtual Hosts to Apache’s configuration settings
Now, we need to add a virtual host to keep any web sites you want to access in the traditional manner working:
This starts by defining a new virtual host and defining its DocumentRoot as C:/xampp/htdocs – this is where the web applications being developed live on our server. I’ve highlighted in red the two places where you need to specify this, and note that it uses forwardslashes, not backslashes. Finally, in green we see the name of our virtual host; in this case, localhost.
Now it’s time to add the virtual hosts for our individual web sites. To do this, we just create another virtual host in the same way as before, but give it a different name and point it to a different directory:
Now, restart Apache. After you’ve done that, any requests Apache receives for “firstwebsite” it will know to treat accordingly, serving your the content from the directory you specified.
Step 2: Edit Windows’ hosts file to tell it where to route requests
If you jumped ahead, gave all that a go and are thinking “why isn’t it working?” then the reason is because although Apache is ready and waiting for requests, Windows has to know where to route these requests to (ie. to your development web server).
To do this, you need to edit your Windows hosts file. This is located in the following folder:
Open the hosts file in Notepad to view it. Note: this file has no extension – that is normal! Unless you’re still using Windows XP, you will need to open Notepad with administrative priviliges in order to save this file. So, before opening Notepad you need to do this:
|Open Notepad with administrative priviliges in order to save Windows’ hosts file|
Right-click Notepad and choose “Run as Administrator”, then click Yes on the UAC prompt that appears. You will see the following line in your hosts file:
What this is doing is telling Windows that whenever you type “localhost” into your browser’s address bar, it should send the request to 127.0.0.1 – which is geek-speak for “home”, ie. that same machine. Ever seen that T-shirt that says “There’s no place like 127.0.0.1” ? Well, now you know what it means.
To tell Windows about your new Virtual Host(s) you’ve made, simply add a line for each one. If your Apache installation is on the same computer that you’re viewing the web site from, then you’ll do this:
However, if you have a machine set up and dedicated as a development web server, you’ll want to enter its IP address instead (for this reason, it’s a good idea to assign a static IP to your dev box).
Now, whenever you enter http://firstwebsite into your address bar, Windows will know to send that request to 192.168.0.15 (your dev box). On here, the request at port 80 (HTTP) is handled by Apache who knows which web site to display because of the Virtual Host we set up in Step 1.