Here’s a very simple solution I came up with this evening. Any input box on the page should be able to “request focus” with a certain level of importance. Whichever input box declares itself to be most important gets focus when the page loads. First, include the following javascript into your page…

var topObjectId; var topLevel = 0;
function requestFocus(objectId, level) {
    if (level > topLevel) { topObjectId = objectId; topLevel = level; }
}
function giveFocus() {
    if (topObjectId) { document.getElementById(topObjectId).focus(); }
}

This sets up a couple of variables to keep track of which object is currently the most important and what its request level is. It also provides a function for an element to request focus and a function to finally grant focus after all is said and done. Now in your website, call requestFocus for each element necessary. It might look something like…

<form id="loginForm">
    <input type="text" id="username" />
    <input type="password" id="password" />
</form>
<script>requestFocus("username", 10)</script>

<!-- ... -->

<form id="searchForm">
    <input type="input" id="searchTerm" />
</form>
<script>requestFocus("searchTerm", 15)</script>

<!-- ... -->

<script>giveFocus()</script>

Here we have two forms, one to login and one to search. In this case, the search form is more important than the login form (15 > 10) and therefore should have focus when the page loads. At the very bottom of the page call giveFocus to actually, ya know, give focus. Deciding the appropriate request level is of course up to the developer, and he will have to come up with his own rules as to what constitutes a more important form.

This certainly isn’t complicated or advanced by any means, but is still nonetheless quite useful. I don’t particularly like throwing these little <script> statements all over the place, but apparently onload doesn’t work for inputs. If anyone has a suggestion for a less intrusive method, I’d love to hear it.

Apache’s VirtualDocumentRoot directive allows you to dynamically set the document root based on the host name that was used to request the document. So what we want to do is to create a unique host name for each website that we’re working on, and have apache find the appropriate document root for that particular site. We’ll start with just one development site - example.com. First we need a place to store the files for this site.. how about ~/Sites/example/public_html/. I put everything in a ‘public_html’ folder because I will often intentionally store some files outside of the document root, such as configuration files that contain passwords and such (for that I would use ~/Sites/example/include/ which I would also then add to my php include_path).

Next we need a unique host name that we can use to access our site. Apache will use parts of the hostname to determine what folder to use, so the easiest thing is to just make them the same… so we will use “example”. (An important thing to note here is that you can’t use a real domain name to access the development site. You could however create your own top level domain to use such as “example.dev”, but it’s certainly not necessary.) Once you’ve decided on a host name, you need to tell your computer that this name should resolve to the local machine. Do this by adding an entry to your /etc/hosts file along the lines of

127.0.0.1   example

If you have more than one development site, they can all be on one line seperated by spaces…

127.0.0.1   example1 example2 example3

Finally, you need to tell Apache to use virtual document roots. Based on the example setup we are using, you’ll want to add the following line to your apache configuration file (/etc/httpd/httpd.conf)

VirtualDocumentRoot /Users/username/Sites/%0/public_html/

In OS X, the virtual host module is not on by default so you will need to uncomment the following lines

# Around Line 205
LoadModule vhost_alias_module libexec/httpd/mod_vhost_alias.so
...
# Around Line 248
AddModule mod_vhost_alias.c

Additionally, you will need to turn off canonical names

# Around Line 503
UseCanonicalNames   Off

Then just restart apache and you should be on your way. For each additional site now, you just need to create a folder in ~/Sites/ and add an appropriate entry to /etc/hosts.

Notes:

• the DOCUMENT_ROOT that your scripts see will still be whatever one is explicitly defined in your Apache config file (something like /Library/WebServer/Documents/), so you may run into problems if your scripts rely on this variable. There is no way that I know of to get around this.

• it is not possible to have separate cgi-bin directories for each site that I am aware of. They will all use the system default one (/Library/WebServer/CGI-Executables/).

  To allow for per-site CGI bins, comment out the ScriptAlias directive in the main apache config file

  # Around Line 672
  ScriptAlias /cgi-bin/ "/Library/WebServer/CGI-Executables/"
  

  and create an .htaccess file in each site’s cgi-bin with the following:

  Options +ExecCGI
  SetHandler cgi-script
  

• reading of .htaccess files seems to be inconsistent. I thought I had them working at one time, but they don’t seem to be right now.

  By default, OS X sets AllowOverride None for user sites, so that .htaccess files are ignored — update this in /etc/httpd/users/[username].conf (not in the main apache config file as one might expect).

• these sites will not be accessible from any other machine unless they know to setup those host names to resolve to your computer’s IP address. This may or may not be what you want — it prevents someone from stumbling upon your development site (security by obscurity), but it makes it slightly more difficult to intentionally show a site to someone else.

• if you still want to run a “main” website for your computer, you can create a virtual host with the name of your machine. For example, if your machine were named “aquinas” and people would normally get to your machine’s website by going to http://aquinas.local/, then you just need to create your site in ~/Sites/aquinas.local/public_html/. You could even just make this a symlinked directory back to /Library/WebServer/Documents/ if you wish for your “main” site to reside there.

• all of the examples here are referring to file locations and configurations that come on a stock OS X Tiger box. Nothing about this is specific to OS X, so just apply the same principles to whatever OS you have apache running on.

After using this technique for a while, I discovered the links I typically (but not always) wanted to open in a new window were those that left my site. I then alterred my javascript function to allow for this and ended up with…

function externalLinks() {
    host = (document.location + "").replace(/^(https?:\/\/)([^/]+).*/i, "$2");

    if (!document.getElementsByTagName) return;
    var anchors = document.getElementsByTagName("a");
    for (var i=0; i<anchors .length; i++) {
        var anchor = anchors[i];
        if (anchor.getAttribute("href")) {
            if (anchor.getAttribute("rel") != "local") {
                if (anchor.getAttribute("rel") == "external") {
                    anchor.target = "_blank"; 
                } else {
                    hrefData = anchor.getAttribute("href").match(/^https?:\/\/([^/]+).*/i);
                    if (hrefData && hrefData[1] != host)
                        anchor.target = "_blank";
                }
            }
        }
    }
}

Call this function when the page loads by changing your body tag to be <body onload="externalLinks();">. This will implicitly cause all links that go off-site to open in a new window while still allowing you to explicitly force any link to open in a new window by using rel="external". Additionally, you can use rel="local" to explicitly force an off-site link to NOT open in a new window. For example, if your site were hosted at www.foo.com, then

<a href="http://www.foo.com/"></a>

would open in the same window,

<a href="http://www.foo.com/" rel="external"></a>

would open in a new window,

<a href="http://www.bar.com/"></a>

would open in a new window, and

<a href="http://www.bar.com/" rel="local"></a>

would open in the same window.

“Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo.” — Brian Moore

I’ve been using mod_rewrite for some time now for various things, but just recently I’ve really started diving into it in order to make cool URIs for skillet.com. The document root is presently a mess, and I want to clean that up for so many reasons, but at the same time I can’t risk breaking existing URLs. It took a good little bit of reading and experimenting, but I finally got mod_rewrite to do what I want.

What I was trying to do was pretty simple… I simply wanted to provide a list of old URLs and have them be redirected to a list of new URLs. This is precisely what RewriteMaps are for, but it took me a little while to really get the hang of them. To save anyone else who is working on this a little time, allow me to explain what I did.

I first created a map file that contained a list of file replacements — first the old file, then some whitespace, then the new file…

#/home/skillet/domains/skillet.com/rewrite-map.txt

/news2/westwood_jan_05.html     /news2/westwood
/news2/grammy-nomination.html   /news2/grammy
/skilletnews.gif                /images/titles/news.gif
/skillet-chat.gif               /images/titles/chat.gif
/skillet-photos.gif             /images/titles/photos.gif
/skillet-pics.gif               /images/titles/pics.gif
/skillet-press.gif              /images/titles/press.gif
/skillet-promo.gif              /images/titles/promo.gif
/skillet-tour.gif               /images/titles/tour.gif
/skillet-video.gif              /images/titles/video.gif

I then added a new RewriteMap, which I chose to name “rewrite-map” (but you can name it anything you want), inside of the skillet VirtualHost. This is the only thing you might have trouble with if you use a shared hosting provider, most of the time you don’t have access to the httpd.conf file, just your .htaccess. (RewriteMaps have to be defined inside the server config or virtual host, though they can actually be used elsewhere)

<virtualhost>
    ...

    RewriteEngine On
    RewriteMap rewrite-map txt:/home/skillet/domains/skillet.com/rewrite-map.txt

    ...
</virtualhost>

Finally, I added the RewriteRule to the .htaccess.

#/home/skillet/domains/skillet.com/public_html/.htaccess

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule .* - [L]

RewriteCond ${rewrite-map:%{REQUEST_URI}} (.+)
RewriteRule .* %1 [L,R]

Now this doesn’t make quite as much sense, so let’s analyze what we’re doing here. The first rewrite condition checks to see if the requested file exists on the file system. If it does, then we simply exit with no changes (that’s what the RewriteRule does) — no sense in looking through the rewrite-map if we don’t have to right? The next RewriteCond takes the requested URI and looks it up in the rewrite-map. If the result is non-null, we continue on; without this RewriteCond, we’d go into a nasty infinite loop of rewrites. Finally, the last RewriteRule replaces the entire URI with the result of the lookup we just performed in the RewriteCond and redirects the user. If the requested file doesn’t exist on the filesystem and there is no entry for it in the rewrite-map, a 404 Error is returned.

If you have a lot of entries in your map, you might consider using a hash file. It provides quicker lookups, but the downside is that you have to rebuild the hash anytime you add new entries. With the plain text map, you can add entries at any time and they’ll automatically be grabbed by apache. If you’re interested in hash files, search here for “hash file”.

So does it work? Try going to http://www.skillet.com/skilletnews.gif and you should be redirected to http://www.skillet.com/images/titles/news.gif.