This website is powered by Blosxom. My main
reasons for choosing this were its size (I originally installed
that sent me way over quota before I'd even put in an entry) and the fact that
it is written in
perl. I'm reasonably competent at writing
now so I felt able to hack
blosxom as needed. In fact, I didn't need to
hack the program itself since it is considerably extendible through its plugin
Although I use Blosxom to generate the site, it isn't really a blog. It's a
regular website that just happens to use blogging software to write it.
Blosxom, especially when combined with the various markup plugins, makes it
extremely easy to add a new section when I write a new paper, give a seminar,
start teaching a new course, or find yet another interesting pizza topping
(that's an extremely obscure reference).
In Sheffield, I ran this as a dynamic website. At NTNU I found that that
wasn't possible so I've shifted to a static version. Unfortunately, that
broke a lot of the plugins: a key difference between static and dynamic being
that for static many plugins get run only once whereas in a dynamic setting
they get run once for each page generated. This means that one has to be
careful how one writes plugins. I had hacked several plugins and hadn't been
careful. After a bit of work, it now looks how I want it to again. It is
entirely possible that I have broken some of the dynamic stuff now but that's
The plugins I use are as follows (in the order they are loaded). Most can be
found from the plugin registry.
I've hacked a few to make them do what I want. Those with significant or
potentially useful hacks are downloadable, but the documentation may be a bit
multiblosxom (no modifications). This is extremely useful for testing an
installation. By running blosxom under a different name I can send my web
pages to a test location to make sure everything works before going live.
static_file_lwp (significant modifications). This is a
modified version of the
static_file plugin. The name reflects the fact that
when I first created this website I had to change one of the perl libraries to
LWP::MediaTypes as the original wasn't on my system. I've since extended it
by adding a subroutine to check if a given file in the
datadir should be
copied across to the web server. This is for static mode only. My
contains files that relate to the configuration of the
blosxom system and
thus shouldn't be seen by the outside world. In dynamic mode, I handled this
.htaccess. In static mode, the solution is simply not to copy things
meta (no modifications). Extremely useful. Allows me to modify the
behaviour of various plugins (see below for which) on a per-story basis.
prefs (no modifications). I don't use this for much at the moment, the
main use is to make the Links section look different to the rest.
styles (my plugin). I wrote this to allow for the inclusion of
style sheets. In dynamic mode it allows for a little customisation by the
user or author of the site by selecting stylesheets, thus adding an extra
layer on top of the flavours. For suitable browsers, e.g. Mozilla-based ones,
it also provides alternate stylesheets which can be selected, say to increase
font size. In static mode, the user can't do much but the author (via the
prefs plugin) can select different stylesheets for different parts of the
site. The customisation in dynamic mode is achieved by CGI parameters; if one
were already using cookies that would be a bit easier. Various other plugins
required modification to take account of this. I shan't note these changes.
menu_count (my plugin). Started life as a minor
modification of the
menu plugin but probably is acceptable to call it my own
plugin now. It provides the menus of the categories, together with story
counts, that you see in the left column. Each menu lists the stories below a
certain base directory (but without listing further subdivisions). I
currently have it set to show the 'Root', 'Sibling', and 'Child' menus. It
checks to ensure that there are no repetitions or empty menus.
simple_view_static (my plugin). This is the
swiss-army-knife of my plugins. After realising the difference between static
and dynamic plugins, I found that the most useful subroutine in static mode is
sort routine. Unfortunately it only gets called once so everything that
I want to be in it has to be in one plugin. This plugin filters the stories,
so that each index page is not overcrowded (it only has the top story from
each subcategory). It also sorts the stories. My method of sorting is to
have a list in each directory of the order of the stories and subcategories.
This divorces the order from the dates, which simplifies matters a little when
you can't rely on timestamps.
seemore (minor modification). Avoids index pages getting too long. The
modifications were so that the syndication flavours (
get the full story and so that it "plays well" with the
markup (my plugin). This is a meta-markup package. It allows
for the choice of markup language on a per-story basis, and for more than one
markup to be used. It also allows for the title to use a different (or no)
markup to the story.
Markdown (no modification). Well, maybe one minor
modification to allow tables to appear in lists and since this is called via
markup plugin, I disabled the direct call.
MultiMarkdown (no modification). See
babytex (my plugin). I wanted to be able to put abstracts of
my papers on the web. Whilst
mathml would be perfect, it is
xml and not
html. Whilst that may be fine for big mathematical blogs, it's not really
suitable for just paper abstracts. That ruled out the otherwise excellent
itex2MML plugin. Also, I wanted to be able to copy the abstract directly
from the paper so I wanted a subset of
LaTeX commands rather than, as
is, a new set. This is designed to work in a similar manner to
the text token by token and expanding it according to rules (as opposed to
pattern matching). I doubt I got it right but it seems to work for my
breadcrumbs (no modification). Anything that helps navigation around
the site is a Good Thing.
cmtime (my plugin). I'd divorced the ordering system from the
date stamps since the latter were too fragile. However, it's still useful to
know when a story was written and when it was last updated. Since I have the
meta plugin, it's easy to add these to the story itself. This plugin sorts
out the fields into the requisite strings.
flavourdir (no modification). Seems a good idea to organise things.
fullcategory (no modification). Not sure if this is really needed in
static mode, but keep it in as ideally I'd like this to work dynamically
without any change and this seems like a reasonable plugin to have on a
interpolate_conditional (no modification). Don't use this much, but
useful extension and, as they say, bytes are cheap (especially in static
prettycategory (no modification). Makes things look a little nicer.
rellink (no modification). Saves having to remember where everything is.
static_entries (my plugin). This isn't really a blog,
it's a website generated by blog software. So not every part of a standard
blog is applicable. In particular, I don't really want the date-style links
to the stories. This ensures that they don't get generated in static mode.
wikiwordish (no modification). Saves remembering locations.
atomfeed (minor modification). Thought I'd play around with syndication.
Not that I expect anyone to subscribe to feeds on this website (well, it might
be useful for students to subscribe to the course feeds) but I wanted to learn
about them so this seemed the easiest way. The modifications allow for the
'Feeds' bit in the upper left corner of each page and only generate the feeds
for the categories not the individual stories.
I said above that I didn't have to modify Blosxom due to the extensive
nature of its plugin system. That's not quite true. In generating the feeds
only for the categories I effectively wanted Blosxom to decide which stories
to generated based on the flavour. There is no way to do this using plugins.
The best I could do is generate an empty page, but the resulting empty file
was still created. Changing Blosxom to check for this was very simple, but
feels as though it goes against the spirit of Blosxom. On the other hand, it