« »
July 17, 2003 » 8:03 pm

Stable URLs in Blosxom

One of the problems with blosxom is that it does not implement truly stable URLs. (Of course, one could argue that no URLs on the Web are truly stable, but that’s a topic for another day.)    (2D)

Bloxom uses the filesystem for data storage and categories. This is one of its distinguishing features. It makes it easy to set up and install, it makes it easy to edit entries (use the editor of your choice, or build your own Web entry system, like wikieditish), and you can easily preprocess entries either statically or dynamically. My blosxom_purple plugin takes advantage of this latter fact, as do many other plugins.    (2E)

Its dependence on the filesystem also has its drawbacks. It’s hard to keep the date of each entry stable, because blosxom uses the timestamp of the file for the date. If you modify the file at all, the date changes. (Plugins like entries_index fix this problem.) Multiple categories are possible via symbolic links, but this is hackish at best. And worst of all, it prevents you from having truly stable URLs.    (2F)

The blog term for such an animal is Perma Link, and the question of the moment is, what’s the proper Perma Link for blosxom? The default flavour suggests that the link should be the date and an anchor link to the entry itself (in case of multiple entries per date). This only works if you don’t modify any of your blog entries, in which case the date will change. If you rename the file, the anchor name will change.    (2G)

I use the category followed by the filename as the Perma Link, because I only wanted a single entry per Perma Link page. Here, the problem is if I recategorize the page (by moving it into a different directory), once again, the Perma Link breaks.    (2H)

These issues will not be a big deal for most folks, but it’s a big deal to me. It means that I have to be extremely careful about my categorization scheme, and I have limited flexibility in changing categories.    (2I)

I want Permalinks that are less fragile. The solution is to separate blosxom’s date and category system from the filesystem itself. This has already been done for dates, and could easily be done for categories as well. The problem is, now you’re getting away from the spirit of blosxom, one of the very features that makes it unique and desirable.    (2J)

Tags: ,

« »

Leave a Reply