When developing websites I like to have my development environment mimic production as closely as possible.
Directory Depth Issues
In particular, I like files to have the same relationship to the web-root in each environment. That is, a file that is in the web-root in production should also be in the web-root in development. And a file which is one directory level down from the web-root in prod should be likewise placed in dev. And so on.
Unfortunately, an out of the box installation of Apache (e.g. with XAMPP) is not configured for this. If we have just one development site and version we can put it in the single XAMPP web-root at our disposal (http://localhost) and all is good. But when we reach the point of having multiple sites ‘and/or multiple versions, things break down. We need to create subdirectories in our development environment to hold each project. But this means that files which are one level deep in prod are now two levels deep in development. Not the end of the world, admittedly, but the extra complexity it introduces in terms of path issues is best avoided. Wildcard subdomains help us do this.
Virtual Hosts
Apache allows us to create something called virtual hosts. They let you give each of those project directories its own hostname and, when accessed through the hostname, files in the root of the project directory will appear in the web-root of that hostname. Problem solved. Sort of. It works, but each time we want a new hostname we have to manually add it to the Apache virtual hosts config file. Bit of a pain.
This is where wildcard subdomains come in. We can configure Apache to accept any subdomain (e.g. http://subdomain1.localhost) and it will automatically map it to the subdirectory named ‘subdomain1’ in the Apache document root (e.g. C:/htdocs). This, if you’re still following me, means that whenever you start a new site or version you can just create a folder in your Apache document root (e.g. C:/htdocs/subdomain2) and immediately start accessing it through http://subdomain2.localhost. No Apache config changes needed.
Configuring Wildcard Subdomains in Apache
To achieve this, first add the lines below to the conf/extra/http-vhosts.conf file in your Apache installation:
DocumentRoot "c:/htdocs" <Directory "c:/htdocs"> Options None AllowOverride None Order allow,deny Allow from all </Directory> <VirtualHost *:80> VirtualDocumentRoot c:/htdocs/%1/ </VirtualHost> <VirtualHost *:443> VirtualDocumentRoot c:/htdocs/%1/ SSLEngine on SSLCertificateFile conf/ssl.crt/server.crt SSLCertificateKeyFile conf/ssl.key/server.key </VirtualHost>
Note that I set up the SSL part may not work for you if you haven’t yet set up a SSL cert. I’d give you instructions on doing that, but it was a while ago and I don’t remember them off the top of my head. Google will know. Otherwise you can just omit the <VirtualHost *:443> part for now and set up HTTP only access.
Next ensure that you have the following line (uncommented) in your conf/httpd.conf file.
LoadModule vhost_alias_module modules/mod_vhost_alias.so
And your done.
To test, create a test folder like c:/htdocs/test and put in a basic index.html file with some html content. Now browse to http://test.localhost – you should see your HTML displayed. If so, your ready to go.
Hosts File Changes
Depending on your setup, you may also need to add this subdomain into your Windows hosts file. To do so, locate you hosts file (probably at C:/Windows/System32/drivers/etc/hosts) and add the following line:
127.0.0.1 test.localhost
You’ll need to do that for each subdomain you add. But if, like me, you’re really lazy you should be able to find a DNS cilent which accepts wildcards. There are some suggestions here, though I’m yet to try them out.
Localhost Location
You may be wondering what happens if you visit http://localhost, with no subdomain. Interestingly, Apache looks for the localhost content in a subdirectory called localhost (e.g. at C:/htdocs/localhost). This means it is equivalent to http://localhost.localhost.
Conclusion
There you have it, a way to simplify your development by streamlining the process of giving each local project it’s own subdomain. This lets you develop knowing that your production environment will have the same directory depths. So root-relative paths will work flawlessly and allow you to keep your code cleaner.
