Serendipity

Blosxom Plug-in: moreentries

The moreentries plugin for Blosxom, which gives "prev" and "next" links when an index exceeds a certain number of stories, did not work if the directory pathname contained special characters for regular expressions, such as '+' or '*' or '?'.

Steve Schwarz, steve at agilitynerd.com, did some good work on moreentries to add multiple prev/next pages, and brought the plugin up to version 0.3.

Version 0.4 (0+4i) solved the special characters bug for moreentries by quoting the regular expression it uses to select postings. It is also safe for Perl's "use warnings" and "use strict".

Version 0.4.1 (0+4.1i) correctly quoted a naked ampersand.

Version 0.4.2 (0+4.2i) added a fix where some installations of CGI.pm didn't give us the expected value of self_url, meaning that prev and next links in categories instead went to the blog top level.

Blosxom Plug-in: last_modified

The last_modified plugin for Blosxom adds an HTTP Last-Modified header to each Blosxom generated page. This reduces your bandwidth needs by permitting browsers and spiders to check for updates to older stories with an HTTP If-Modified-Since, rather than retrieving the full page each time. It also allows proxies such as Squid to cache older entries whilst refreshing correctly when newer ones are added.

By default this plugin will scan the list of stories and use the timestamp of the most recent one as the Last-Modified header.

The plugin uses the timestamps in %blosxom::files, so it is compatible with entries_index_tagged and other plugins which set the story time, as well as with standard Blosxom use of the storyfile.txt modification time.

Other plugins may if they wish place a standard Unix timestamp in $last_modified::last_modified to override the default Last-Modified time.

Blosxom is a CGI script and, in its usual configuration, it considers everything under $url as a Blosxom request. This makes it awkward to serve up static files (for instance, images, movies or tarballs) from anywhere under the Blosxom root URL. You typically receive a cryptic message such as 'Error: I'm afraid this is the first I've heard of a "mp3" flavoured Blosxom. Try dropping the "/+mp3" bit from the end of the URL.'

There are a couple of plugins which attempt to deal with this - e.g. binary and static_file - but both have the disadvantage that the Blosxom script is still invoked for each static file. Of course you can put all your static files in a /images/ directory or similar outside the weblog, but keeping track of a large number of images then becomes cumbersome.

It must be better to let your webserver handle static files, a task for which it is optimised, rather than invoking a CGI for each image. For instance, in apache httpd.conf, if your blosxom script is named /usr/lib/cgi-bin/blosxom:

Requires Apache mod_rewrite (run a2enmod rewrite). Of course this will bypass any Blosxom authentication or restrictions, and any remote user who can guess a filename under the Blosxom tree can retrieve it even if it's not linked from anywhere. You should make sure that no unwanted files are accidentally exposed in your Blosxom tree and that any source or passwords are held outside the Blosxom <Directory>.

This doesn't affect the static rendering of dynamic Blosxom pages, which are held in $static_dir and not served directly. Although if you do use static rendering, you could get even cuter with your rewrites - mail me if you have any further hints and I'll put them up.

Thanks to Gavin Carr on blosxom-users for the idea.

I wanted to give you a meaningful <title> element according to the story or category you are reading. Here's the existing storytitle plugin, which takes the page title from the current story, modified by myself to add category titles. Depending how you are accessing this story you may see the browser title bar as "Serendipity", or as some substring of "Serendipity : Software : Projects : Blosxom", or "Serendipity : Hacking on the storytitle plugin". Now before you all shout I know there are half a dozen other plugins which do this :-) This is as much an exercise in plugin documentation to keep my hand in, until I have time to attack Blosxom itself !

Serendipity is coded in Blosxom, a lightweight text-based weblog written in Perl. I've been talking on the Blosxom Developers mailing list about taking Blosxom back on maintenance and enhancement in an organised way. In the meantime I'm also trying to get some of the content published for which I actually chose Blosxom ! Here's the result of a bit of hacking on the photogallery plugin: Shefstock 2007.

The neat result is thanks to the original authors, but I've updated the documentation with suggested usages and techniques. I also added a feature to help integration by reading .caption files from the web gallery software called igal. I have quite a number of igal based photo galleries, and this will make it much easier to bring them across into Blosxom. I hope to add other useful gallery formatting options to photogallery, and to be able to preserve the igal look for existing igal galleries if it can be done easily.

From: Nick Leverton
To: blosxom-devel@lists.sourceforge.net
Subject: Re: [Blosxom-devel] Project status?
Date: Wed, 1 Aug 2007 18:03:49 +0100
Message-Id: <200708011803.53695.nick@leverton.org>
In-Reply-To: <20070801072437.GA19249@katherina.student.utwente.nl>

On Wednesday 01 August 2007 08:24, Matthijs Kooijman wrote:
> > This then gives a way to move Blosxom forward by taking the canonical
> > plugins as mainstream, so that the relevant features will work in the
> > same way for all plugin authors.
>
> Another thing that would be useful is to define some standards for how
> plugins should (roughly) do their work. In particular, it would be useful
> if plugins could define their own hooks, which yet other plugins could
> fill in. These hooks could be somewhat standardized (ie, all the
> different comment plugins calling a "spamfilter" hook that other plugins
> can use to implement blacklisting, or captcha's or stuff like that.

Certainly. In fact I've seen another plugin implementation, the one in
qpsmtpd, which has some neat ideas that I've thought about borrowing - many
of them are included in my lists below.

The following seem to me to be essential principles to help us get on top of
the plugins and base Blosxom functionality. I think they ought not to be
too disruptive to the existing code base. Some of them are things others
folk have mentioned here, which I hope I've represented fairly.

If we are going to get Blosxom more widely used, we will need both to make
packagers' jobs easier and also to make it simpler to configure a package
without editing static files, so I have tried to have regard for that as
well.

• As far as possible, any changes should be backwards compatible. If an
  incompatible change is unavoidable then consider introducing a new hook
  instead and deprecating the old one.
• All plugin hooks should work in the same fashion
• All plugin hooks should support being hooked by many plugins (and the
  plugins should cater for it too)
• The effect of having multiple plugins on one hook will be defined (and, so
  far as possible, will also be useful !)
• As far as possible, the order of plugins should not matter. Consider
  introducing new hooks where this would make logical sense.
• If ordering the plugin calls is unavaoidable, it will not require renaming
  files (though this can still be done, for backwards compatibility).
• So far as possible all dynamic information will be cached. There will be
  standard routines for accessing filestore through the cache.
• All plugin configuration will be supported via an external config file,
  without the need to edit the plugin code.
• Failure of or inside a plugin will not lead to failure of the entire
  weblog (this one has caught me so many times as I try out plugins !)

These are some thoughts about important but IMO less essential principles,
which might make it easier to implement some plugins or which address some
of the other concerns raised here:

• Plugins may choose whether to work on the semi-rendered output of the
  previous plugin, or on the un-rendered original. Default will be to
  continue on the previous output.
• Plugins may choose whether blosxom should continue processing a hook or
  whether the posting is now complete as far as this hook goes. Default will
  of course be to continue processing.
• It will be simple to define additional hooks for user requirements.
• Plugins wil lbe able to conditionally call hooks in other plugins (for
  interpolate_fancy etc).
• There will be a standard way for plugins to keep state. This will be
  cached and integrated with the dynamic information cache. It should also
  support non-cached BLOBS of some kind, for gallery plugins etc.

Any comments, additions, deletions please ?

From: Nick Leverton
To: blosxom-devel@lists.sourceforge.net
Subject: Re: [Blosxom-devel] Project status?
Date: Tue, 31 Jul 2007 13:03:54 +0100
Message-ID: <20070731120354.GC25392@leverton.org>
In-Reply-To: <A10A315B-8AD7-4FC8-8205-146494EBDDD4@barijaona.com>

On Tue, Jul 31, 2007 at 07:11:40AM +0300, Barijaona wrote:
> I'd prefer not change the spirit of blosxom, but recognize that its
> learning curve is really frustrating. So I suggest the following
> evolutions :

I very much agree that Blosxom is still a useful piece of software but
desperately needs updating in some areas. I write as someone who's set
out to evaluate several weblogs lately, including Wordpress, but who
has come back to Blosxom as by far the lightest-weight weblog for my
pathetic little 80Mb virtual hosting - not to mention having the least
complex code to hack on :)

For instance, many useful plugins are undergoing link rot as their authors
convert to other blog software and take down their Blosxom installations.
I spent ages last night looking for autoblock, textile and twikirender,
any one of which would have done to simplify my post formatting - all
have apparently dropped off the net. I can probably hack up a textile
plugin myself, it looks trivial, but I'd prefer if I didn't have to !

> - one should consider rehearsing blosxom's regarding its default
> interpolate routine and XML feed. Most users are expecting something
> more up to date in these areas, so why not give them out of the box
> the functionalities of interpolate_fancy and atomfeed ? The current
> situation makes blosxom appear really outdated.

> - there are a couple of blosxom starter kits (including a selection
> of plugins and flavours) floating around. We could encourage the
> creation of similar kits through "official" changes to the
> configuration variables in blosxom.cgi.

I agree it would be a worthwhile effort to gather together a set of
"recommended" plugins which we can then document, support, bugfix,
and accept enhancements for. Depending of course whether the plugin
authors agree, but most of them seem to have used the Raeality licence
so it ought to be a formality.

This then gives a way to move Blosxom forward by taking the canonical
plugins as mainstream, so that the relevant features will work in the same
way for all plugin authors. This will reduce the interdependency problems
I've run across, which are not always even declared in the perldoc.

I don't know if the Debian maintainer Gerfried Fuchs is here
directly ? I helped look at a security issue in the Debian version,
http://bugs.debian.org/423441, and though it's not an exploitable issue
in mainstream Blosxom I would very much like to improve the coding style
(apparently left over from Blosxom's earliest days) that let the loophole
creep in.

I have other vaguer ideas too, along the lines of overhauling XML and
interpolate() as you do, but just getting blosxom back into development
would be a great start !