This site is a mixture of static content and dynamic content served through the Blosxom blogging system. I use various URI rewriting rules and a number of Blosxom plugins (some slightly hacked) in order to implement the site according to my personal design philosophy.

Overall implementation

As mentioned above, my site is (for the most part) powered either directly or indirectly by Blosxom. I use three different approaches to serving site content:

  • All weblog pages (including the site home page) are dynamically generated by Blosxom.

  • Most remaining (non-weblog) pages, eventually including all my writings, are statically generated by Blosxom, with the resulting HTML files then copied into the document root directory.

  • The remaining web pages and other files (e.g., images, PDF files, tarballs, and the like) are traditional static web content. Over time I'll migrate as many of these files as possible into Blosxom (among other things, so I can take advantage of Markdown for text formatting).

The site is hosted by an Intel server running Apache and Linux; since I administer the server I have complete control over the Apache configuration, and implement extensive URI rewriting to integrate the three types of content together in a reasonably seamless manner.

I use Subversion to maintain a version-controlled repository of all the files needed to (re)create the site. (One of the reasons I chose Blosxom was because it stores weblog content as regular text files in the file system--as opposed to in a relational database like a lot of other blog software--and thus is very appropriate for use with a version control system.) I then use GNU Make to automate pushing new content to the site or updating existing content.

URI rewriting

My overall goal is that URIs used to request site content should be entirely independent of the techniques used to serve the content; I use URI rewriting to achieve this goal. In general, if a requested URI refers to existing static content on the site then that content is returned directly by the web server; otherwise Blosxom is invoked to resolve the URL and generate the appropriate content. However there are exceptions; for example, we force URIs referring to certain pre-existing directories (e.g., /mozilla) to be instead interpreted as Blosxom categories.

I implemented the URI rewriting rules directly in the httpd.conf Apache configuration file (actually, in a file included by that file). For more information, including the actual rewriting rules, see my discussion of URI rewriting and canonical URIs.

Extensionless URIs and URI redirection

I wrote two Blosxom plugins to implement my chosen URI scheme. The extensionless plugin allows use of URIs without file extensions to refer to individual entry pages. The canonicaluri plugin forces redirects on category and date-based archive pages if the URI omits a trailing slash, in order to emulate standard Apache behavior for URIs referring to directories; it also forces a redirect if a URI for an individual entry page includes a (spurious) trailing slash or an unneeded .html extension.

Two-column "liquid" layout

I implemented the site layout using the techniques described in the article "Creating Liquid Layouts with Negative Margins" published on the A List Apart site. However I didn't implement the full set of techniques because I wasn't using background colors or images.

Submit a comment

Please enter comments as plain text only; no HTML tags are allowed. All comments and trackbacks are moderated, and will not be displayed until approved by the moderator.

Comments are closed for this story.

Trackbacks are closed for this story.