A blosxom feature wishlist (a Request for Engineering for blosxom 0.5i).

After writing so nicely about blosxom (the article was written about 0.5i which is the current official version) it's time to see what made me wish for a little bit more (but without breaking blosxom's less is more approach). We are currently running three copies of blosxom on our site. Hopefully someday one copy is all that will be needed. It looks like the next version will at least make my primary wish come through. This is my prioritised wishlist:

• blosxom has a static num_entries variable for the number of entries to show up on your blog pages (not just your blog index page). You might want to have a different number of entries showing depending on where you are on the site. At the moment we have to run a separate copy of blosxom for generating the archives pages with num_entries set to 9999 (i.e. show all entries) in addition to our normal copy (with num_entries set to 5). This is unnecessary and it looks like Rael has realised this. We have been using this crude 9999 hack since November last year to show all articles in the archives - but DJ has posted a more elegant solution.
• The fn variable is the relative pathname of the file and not just the filename itself. I have not found a way to dynamically create permalinks based on path/filenames. At the moment I have to include static html pointing to the file location for the permalinks. Blosxom's (working) date based permalinks are really no use to us since some of the articles are updated several times.
• the current version supports the .txt file extension only. It would be nice if any file extension (.blsxm ?) could be configured. There are good reasons for not using .txt: downloadable .txt files on your site, your search engine might generate .txt files or simply preference. It would also be nice if you could pass this on (like a flavour) to blosxom.
  
  I have given up on using bookmark managers and have instead opted for letting blosxom maintain the bookmarks by replacing all .txt occurrences in the code with .ln (that's the site's 3rd copy of blosxom then). With a simple sdln flavour and using lists inside the .ln files I have a quick and ready made bookmarking system and my bookmarks are always "with me". Crude I admit, but it works. It also fits in very nicely with blosxom's overall "path philosophy". Now if a file_ext variable existed I could make these bookmarks available through an unobtrusive little link on each page in my directory tree. This would help some blogs avoid the "glorified link list syndrome". To clarify I have shown a links example in this post itself (the little "links" displayed after permalink and path under the title on top of this article). This could easily be extended; an example would be a small "books" link - pointing to relevant books (on amazon). My bookmarks are publicly available as well.
• To clarify the above two points. Here is how the code for the line under the title is currently displayed (hardcoded in the .txt file):

  <span class="sdcreate">
  |
  <a href="http://www.sundot.com/cgi-bin/blosxom.cgi/net/blog/#blosxomrfe">permalink</a>
  |
  <a href="http://www.sundot.com/cgi-bin/blosxom.cgi/net/blog">path</a>
  |
  <a href="http://www.sundot.com/cgi-bin/blosxln.cgi/net/blog">links</a>
  |
  initial version: 20030122
  </span>
  

  I would like it to look something like this (inside of my story file instead of in the txt file!) where
  • dirname would always be net/blog for this post (generated by using pwd and then cutting off the datadir part)
  • filebname is just the filename (not including the path) without the txt extension
  • blxurl does not change
  (This is in fact how I presumed path, fn and url worked when reading the documentation ...)

   
  <span class="sdcreate">
  |
  <a href="$blxurl/$dirname/$filebname">permalink</a>
  |
  <a href="$blxurl/$dirname">path</a>
  |
  <a href="$blxurl/$dirname?file_ext=ln&flav?=sdlinks">links</a>
  </span>
  

  The way blosxom changes the values of url, path and fn relative to where you are in the directory makes them unsuitable for constructing permalinks based on filename. Observe how the values of these variables (yes - even url) change (it's the same post) when moving from net/blog to net/blog/debug.
• blosxom generates a date as output between different dated blog entries and this will show up on your webpages. It should be possible to turn this off - it's the only output from blosxom which is not generated by the normal .txt entries. I turned this off by commenting these two lines out (lines 106 and 107):

  #       $content_type eq 'text/html' && $curdate ne "$dw, $da $mo $yr" &&
  #	        print span({-class=>'blosxomDate'}, $curdate = "$dw, $da $mo $yr");
   

  When leaving these lines in I could not find out how to change the look (like colour and font) of the generated date. This is the only "uncontrollable" part of blosxom I have come across and as such breaks the user control of the page layout (I am not a perl programmer so I admit I might have missed something here).
• a variable pointing to a directory for storage of flavours. Since we parse from our top level directory the head,story,foot files (we have 5 sets) all end up in document root. I would like to have these in their own subdirectory.
• SSI #include statements are not understood/parsed. This causes me to have two copies of the header and footer pages. One set for normal shtml files and one for the blosxom entries (where the code in head.html is duplicated from common/header.html).
• the time is given as HH:MM only. If I wanted to use a full ISO datestamp like 20030122T1940 for my weblog I couldn't.

Why blosxom is the right weblog tool for a professional or small business site.

When setting up this website a few years ago it contained just a few static pages with some basic company information and a CV. It was dead easy to maintain. As soon as a site grows writing static html (using templates) can become a chore and if the sundot site was to expand other tools than vi and some html templates were needed.

Blosxom is a simple weblog application (less than 120 lines) written in perl and turned out to be the best choice for us.

We looked at other systems like:

• a wiki like twiki (really best for a multi user intranet or an active community site).
• moveable type (widely used, looks to be a very nice content management system. But it's not exactly minimal and it's $150 for a commercial license).
• greymatter (free, but no longer maintained).
• blogger (the main driver behind blogging, but you have to go through their site to post and the pro version is not free).
• others: radio userland, geeklog and many more.

why is blosxom better than the others?

• there is no database: as html pages are generated on the fly (using normal .txt files) they are simply processed from their normal file system location. There is no checking in/checking out of files. There is no rebuilding of database(s) when adding a new entry (page). Pretty much all of the other blogging software use some sort of database and needs "rebuilds".
• no need for a separate "archive" area : one .txt file is all that is needed. The datestamp on the file itself decides where it shows up in your blog. Your "archive" is simply a different way of accessing this one .txt file.
• security: since there is no database there is no vulnerable admin user login. blosxom relies on the (unix) file system so you are in complete control over your file permissions (other weblog software set file permissions to rw-rw-rw (public write!), rw-r--r-- is enough for blosxom).
• minimal: since it is so small configuration is really easy (provided you have some very basic editing and unix skills). In fact blosxom is a tool in the true unix tradition: it performs one task and it performs it well.
• compliance can be achived: blosxom does not put itself in the way of web standards. It can be used to generate w3c compliant html/xhtml web pages (as well as use css as the sundot site shows :-) ). Now you would have thought this was of importance to the developers of blog software but try to validate the home pages of any of the alternatives (mind you raelity.org does not validate either). The best of the lot is the Moveable Type home page which just generates 6 errors.
• previous knowledge: if you have any editing, html, file system, unix and/or perl skills blosxom is ideal. I have no perl knowledge (apart from knowing that my O'Reilly perl book has been standing in the bookshelf for a couple of years now ...) but was still able to easily install blosxom and even customise it slightly.
• non-exclusiveness: all the above means that you can continue to use your favourite tools. Write .txt files directly on your webserver with vi or use your favourite editor on Windows; use rsync/ssh for easy content management or (not so) good old ftp; use cvs for source control, use stylesheets for the design ...

In short: blosxom is easy to install , easy to maintain and the author Rael Dornfest reckons you can have a blog up and running in 15 minutes. Blosxom is so good that we run it straight from our document root. But it is not perfect.