This website is powered by Blosxom. My main reasons for choosing this were its size (I originally installed geeklog but 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 perl programs 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 facility.

---

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 life.

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 minimal:

1. 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.

2. 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 datadir 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 with .htaccess. In static mode, the solution is simply not to copy things across.

3. meta (no modifications). Extremely useful. Allows me to modify the behaviour of various plugins (see below for which) on a per-story basis.

4. 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.

5. 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.

6. 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.

7. 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 the 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.

8. seemore (minor modification). Avoids index pages getting too long. The modifications were so that the syndication flavours (atom and rss) always get the full story and so that it "plays well" with the styles plugin.

9. 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.

10. Markdown (no modification). Well, maybe one minor modification to allow tables to appear in lists and since this is called via the markup plugin, I disabled the direct call.

11. MultiMarkdown (no modification). See markup and Markdown.

12. 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 itex is, a new set. This is designed to work in a similar manner to TeX: parsing 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 abstracts.

13. breadcrumbs (no modification). Anything that helps navigation around the site is a Good Thing.

14. 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.

15. flavourdir (no modification). Seems a good idea to organise things.

16. 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 dynamic system.

17. interpolate_conditional (no modification). Don't use this much, but useful extension and, as they say, bytes are cheap (especially in static mode).

18. prettycategory (no modification). Makes things look a little nicer.

19. rellink (no modification). Saves having to remember where everything is.

20. 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.

21. wikiwordish (no modification). Saves remembering locations.

22. 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 works.