On the MailingList, a frequently asked question is, how to prevent that a posting moves to the top of the blog because with a modification (e.g. a fixed typo) the modification date of the file changed and blosxom uses this file as the posting date.

This article shall outline the solutions to this problem, which were suggest in the thread started with this mail on the MailingList.

There are at least three different concepts to solve this problem:

• Letting blosxom remember when it first saw this posting and let it keep that date by using a plugin.
• Setting the date through meta data inside the article or the article's file name and let a plugin tell blosxom that date.
• Setting the date through meta data inside the article or the article's file name and ressetting the file modification date after changes based on that data manually or by a manually called, local (shell) script.

We will focus on the first two concepts here.

The oldest and some kind of a no-frills plugin to preserve the posting time automatically is Rael's entries_index which caches the file modification time when it first notices a posting.

The plugin entriescache is based on entries_index and offers the same functionality, but also caches all story data for a configurable number of minutes and therefore reduces the number of accessing all posts on the harddisk to one access all few minutes.

Both plugins are also available in a variant which lets you set the time by including it as a meta tag into the post file: The plugin entries_index_tagged works like and is based on the entries_index plugin but allows to include date and time information in the Unix time stamp format (seconds since Jan 1st, 1970 00:00:00 GMT). You should install the meta plugin, too, to make this plugin work as expected.

The caching variant is the plugin entries_cache_meta. It has some more features, so it accepts at least one much more human readable date format thanthe Unix times stamp format and — if the Perl module Date::Parse is installed — all formats that module can parse.

Carl Camera at i am a camera is running Blosxom on IIS and had problems with the writeback plugin. He asked for help on the MailingList to no avail. Fortunately he found the solution on his own.

For the record, the problem occured in the if statement when determining if a POST was issued from the writein plugin. IIS does not seem to be returning values from the plugin('value') calls. I pulled all the variables that are checked in this statement out and the check looks like this now:

$isPost = ($getpost eq 'POST');
$isWrb  = ($blosxom::flavour eq 'writeback');
$isTkb  = ($blosxom::flavour eq 'trackback');

# Only spring into action if POSTing to the writeback plug-in
if ( $isPost && ( $isWrb || $isTkb ) )

Carl also notes that it seems that if you are a user of IIS or any other non-unix based OS (like MacOS <=9) you're kind of up the creek without a paddle. From my own experience with Blosxom this is unfortunately true. It seems that almost all Blosxom users are on some flavour of *nix, so if you have issues with IIS or some other webserver/Perl installation you might not be getting answers simply because, in reality, no one may have any clue how to help you.

We'll try to post more IIS specific articles as they come along, but looking through my archives there just haven't been very many questions and no clear "go to" person as a sounding board. Hopefully more people like Carl will contribute to the list!

UPDATE 2006.06.21: Carl informs us in the comments that he's moved to another system but that the files/articles are still available here. Thanks for the update, Carl!

Mary Harrsch wrote a tutorial for installing Blosxom on the University of Oregon's Darkwing system. I'm not sure how old it is, but it is still relevant, and has some downloads (actually a fairly complete starter kit, similar to other kits) and useful graphics showing you where things are going. The graphics are from a windows machine going (apparently) to a *nix server. Here is the link to the article.

If you are interested in using Blosxom and speak Chinese this site, put together by Shelandy, might be of use to you.

A while back Jason Silver was having issues getting a site to work. He discovered that the site's host was using CGIWrap to handle cgi scripts which was adversely affecting blosxom.cgi. Geoffrey Alexander sent him a fix, which goes in the blosxom.cgi...

# Path Info Magic
# Take a gander at HTTP's PATH_INFO for optional blog name, archive
yr/mo/day
##This is the fix for CGIWrap
#my @path_info = split m{/}, path_info() 
     || param('path'); # <--changed to:
my @path_info = split m{/}, $ENV{QUERY_STRING};
##

In otherwords, my @path_info = split m{/}, $ENV{QUERY_STRING}; replaces my @path_info = split m{/}, path_info() || param('path');. However Jason discovered this didn't completely resolve the issue. He found that this code, which replaces the same single line in blosxom.cgi, did work...

my $script_uri = $ENV{'SCRIPT_URI'}."/";
$script_uri =~ s/$url\///;
my @path_info = split m{/}, $script_uri;

In his words:

Basically what was wrong was the way Blosxom was reading the URL. path_info() wasn't filled the way it is normally filled when CGI Wrap isn't used. But using QUERY_STRING doesn't completely solve the problem because it only will contain information when a question mark is used, and so many plugins will break etc.

I used SCRIPT_URI instead of SCRIPT_URL so I could make use of the $url variable in Blosxom. This means you should fill this variable, not depend on Blosxom to guess it. Also, if you call the script from a SSI anywhere else then you'll need to hard code a way to remove the this additional URL.

Hopefully this helps others out there. Remember, if you can't get Blosxom to run on your hosted site, check with the host's admins and see if they are using CGIWrap.