Nowadays we almost systematically create database-generated websites. URLs are thus written on-the-fly and we usually call pages through query string, like:

http://example.com/index.php?type=article&id=25&date_written=20020322.

What I call "clean" URLs is what you can see on evolt.org, for instance. In my example the URL would be:

http://example.com/article/200203226.

Let us assume that this article was the 6th written on the 22nd of march, 2002 and that we store this info in our database, see below, Structuring your data). The purpose of this article is to show you how to switch from the former to the latter with Apache and PHP through a simple example.

Note: there's nothing polemic about this "clean" qualification. Anybody who finds a better name is welcome to use it instead...

What's the use of switching from query strings to "clean" URLs?

Dropping query strings and using these so-called "clean" URLs:

Need we say more?

Structuring your data: creating unique identifiers

First and foremost, think of the data stored. You have to be able to give a unique identifier to each article. So instead of (or in addition to) using an incremental id you must think of a unique, not-to-be-changed-in-the-future identifier.

My method in our example is this: create a field uniqid and give it the date concatenated with the rank of creation within the day. In my example my article's uniqid is 200203226 (the article was the 6th created on the 22nd of March, 2002). Of course one can imagine a situation where only one article is written per day. Thus maybe this uniqid field is redundant if you store the date the article was written. Or it can be YYYYMMDDHHmmss to have the whole date and no rank. [insert here any other naming method you like].

Note: there are many other ways to store your articles. Maybe they're each in their own text file in a dedicated includes directory and then you call them through an inclusion, maybe they're extracted from an XML file, etc. That's why I'm not too specific on the storage of data here.

The 'article' file: parsing the URL

Now we will create the article file using standard PHP code, even if, as you noticed, the file has no .php extension. We'll come back to this issue below, in Using Apache's ForceType. Here's the code for our article file:

<?php

/* 1. parse the URL */

$expl = explode("/",$HTTP_SERVER_VARS["REQUEST_URI"]);

$article_id = $expl[count($expl)-1];

/* 2 security check */

[omitted for the sake of simplicity]

/* 3 populate the page with uniqid's content */

[omitted for the sake of simplicity]

?>

Here's how it works:

  1. Parse the URL (REQUEST_URI) by exploding

    it, fetch the results in an array ($expl) and assing to $article_id

    the last occurence of the explosed array.
  2. Check any security needed and stop the code on error. There's no reason

    to parse the page any further if what's passed to $article_id

    is not correct. In particular we'll check the following:

  3. Populate the page with the content corresponding to the uniqid

    equal to $article_id.

Using Apache's ForceType

At first I tried creating "clean" URLs and redirecting them through 404 errors to the index.php, for example, which would then parse the URL and write the page accordingly. I ran into unsuspected trouble checking my system with Lynx: a 404 error is an error (yeah, right). So I guessed search engines would stop on this error. Damn. My world domination (© glassdog) scheme goes down the drain.

Enter ForceType. This Apache directive forces the server to consider a file as being of another type than what is expected by default (see Apache's documentation on ForceType).

We will now use the <FilesMatch> directive to specify which file is to be considered as a PHP file and not a plain ol' text file, which is the default on most servers (see Apache's documentation on <FilesMatch>).

Don't worry: even if you can't configure Apache directly because your hosting provider doesn't allow it, I've got good news: you can do it through a .htaccess file.

Here's a sample .htaccess I wrote in my root directory:

<FilesMatch "^article$">

ForceType application/x-httpd-php

</FilesMatch>

The result is: Accessing http://www.example.com/article/200203226 tells the server to consider article as PHP, then parse the URL, and push the content whose uniqid is 200203226 into the template. And voilà. We're done.

Conclusion

To sum up this very simple example:

  1. Call "clean" URLs when writing your code
  2. Create as many templates as needed for each type of parsing
  3. Specify their type in .htaccess

Your URLs now have a chance to be as permanent as their domain name.

For more server-side fun, you can include the same template in all the ForceType'd pages so that all the formatting will be written only once. You can also, like often in evolt.org, create longer URLs and parse them as a set of several parameter/value pairs. Be careful with that, though, because you may force search engines to index too many occurences of pages. Oh, well, maybe that's what you want after all...