Framework for Development Web Servers

by Nathan Wallace (May 25, 1999)

Web site developers need fast and easy access to documentation, development servers and released sites. Setting up your development web server with a consistent framework is the easiest way to meet these needs.

Framework Assumptions

I use a single Linux box to do all my development. Although this framework is based on a single machine setup, the techniques could be used in a team/network environment.

Fast and Easy Access

The easiest way for an e-gineer to access information is with a web browser. When working I already have browsers open for viewing my work and browsing the net.

There are two ways to make information easy to find with a browser:

Since my bookmarks seem to get out of hand extremely quickly I find simple domain names are best. Bookmarks also have the disadvantage of being tied to a particular users browser. This means that when I log into my box as root for some reason I no longer have access to all of the bookmarks from my normal working account.

Simple Domain Names

We are going to play God and create two new domain levels:

The new .doc top level domain (TLD) is used for referencing documentation with our browser.

Sites currently under development get a special URL which points to the development web server.

Read my Apache Installation Instructions for more information on setting up these simple domain names on your machine and for your web server.


Almost all documentation is now available on the web in HTML format. Unfortunately I can't afford to be connected to the web permanently and my connection is too slow to jump around the often massive documentation HTML files. Worst of all, I have to dig my way down to the doc since I can't find anything in my huge bookmark list.

So, I download the documentation and install it under my own local web server. I usually create a domain for each documentation set, eg: mysql.doc, php.doc, apache.doc and so on. Now the documentation is always available, fast and easy to find.

Development and Production Sites

Keeping the pages and code separate for the development and live versions of the site is important because you:

One important aspect when programming pages for this configuration is to avoid the use of the server name when linking. The page for this article is in the same directory as my articles contents page. There are a number of ways that I can link back to the contents. The three principal techniques are:

Similarly, linking back to the main page of this site can be done with:

The links that contain the explicit reference to are not suitable for testing on the development server. Every link will take us to the live web server. When we link to the file location only, the links point to within the current server, allowing us to test using the development server.

The best solution is to use relative file name links, the final case in the examples above. This gives us the freedom to use different server names and to move the location of the file hierarchy without changing all of the links. Currently is running as a virtual host, which is why the url for every page starts with instead of If these pages are moved to their own server (thus losing the /e-gineer part) then using relative file name links will mean that I won't have to change all of my links. This is not extremely important since links must live forever.

I keep an exact copy of the pages and file struction on both servers. This gives me the chance to create freely in development and upload the changes when I am ready. The added advantage is the protection of having at least two copies of your web pages.

Use a consistent directory layout when working on multiple sites. Here is an example:

    /www/servers/    - serves pages for
    /www/servers/ - serves pages for
    /www/servers/apache.doc   - contains apache html manual for apache.doc