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 !

Igal is a jolly useful little web photo gallery generator which is easy to get started with. You run igal in a photo directory and just upload the resulting HTML and processed images. It's probably most widely recognised for the default "film strips" effect, but you can customise the appearance quite well via its generation options and CSS. At the time of writing you can see some of igal's output in varying states of customisation in the Tunnels section of this website. Igal is written in Perl.

I submitted an improvement concerning file mtimes to the author Eric Pop. He wrote, "this does seem useful, and if i do get around to releasing igal 1.5 at some point, it will definitely make it in there!" I subsequently submitted that patch and a couple of others to the Debian maintainer of igal as well.

However Eric's own igal page seems to have dropped off the net so I am mirroring the work I've done on Igal here. I am hoping that I can hack on photogallery to the point where it can replace igal for my needs, so my Igal category may become purely historical in due course except to document these changes.

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 !

What Is It ?

Qmail is a modern replacement for sendmail, written by Dan Bernstein, who also has a web page for qmail. qmail is a secure package. There was a $1,000 prize for anyone who can show otherwise, which went unclaimed. Qmail is being increasingly used by savvy and security-conscious admins on the net. You can read more on qmail, including many other useful patches which work with it, on the Qmail Users' web site.

I've created a simple patch to qmail, which greatly simplifies the use of it on dial-up hosts. Until now it was not quite ideal for dial-up use, as it assumes the remote delivery path is always available, which when using dial-on-demand meant by default it would dial up straight away to deliver. This required additional software such as the use of serialmail, or else stopping and restarting qmail upon connection to pick up new parameters.

With this patch, which modifies only qmail-send, it's possible to hold and release the remote delivery queue at will, using a new parameter "holdremote", which will be re-read when qmail is kicked with a SIGHUP. Thus outgoing mail can be queued as normal, but with the holdremote flag set it will not be delivered. When going online, arrange in your ip-up script for the parameter to be unset, tickle qmail-send with a SIGHUP, and Roberta is your mother's senior sibling - all queued remote mail will be immediately rescheduled. When you go offline, set the flag again and re-SIGHUP qmail-send: any futher mail will be queued for next time.

There is also a holdlocal option for symmetry and because it virtually fell out of the code, should anyone find a use for it.

Why use this patch ?

Advantages of my method over serialmail are:

• serialmail is additional software and configuration beyond the basic qmail package which a user may download first time; with my patch there is no additional software (except the patch, obviously) or configuration.
• serialmail requires a looping call should more mail be queued whilst online; this requires installation of still another DJB package (daemontools). With my patch, further mail is delivered instantly by qmail as designed, with no extra load or complexity.
• multiple serialmail instances can end up being run at the same time (for instance if using diald set up by a naive admin) unless, again, daemontools are used, thus resulting in duplicated mail; with my patch, this cannot happen as only a qmail parameter is changed.
• using serialmail to forward to a smarthost restricts the amount of mail which can be sent at once; by sending the mail directly it can potentially be sent faster, as the full bandwidth of your outgoing link can be used by dispatching several mails at the same time.
• Using a smarthost introduces an additional Single Point of Failure into your outgoing mail. Dispatching it directly to remote hosts using their MX records avoids this.

You do not need (though may still want) this patch if:

• you have a permanent network connection for outgoing remote mail.
• you have a dial-up link but not over IP.
• you send remote mail immediately it's queued via a dial-on-demand dial-up IP link and are happy to continue to do so (typically applies to people who don't pay their own phone charges :-)).
• you send remote mail to different destinations via two or more different links (e.g. internal-to-work and net-at-large). In this case you will require serialmail, which is an excellent package for this purpose.

Download this Patch

At the time of writing, qmail is at version 1.03. There are versions of this patch for use with both qmail 1.01 and qmail 1.03. You need the qmail sources, to which you add this patch using the following command:

zcat qmail-hold-<version>.pat.gz | patch -p0

Then compile and install - simple as winking !

Using the Patch

Here are some script excerpts which illustrate how I use it.

Firstly, an extract from the script which runs when my PPP link to my ISP comes up (in my case /etc/diald/ip-up):

{ rm -f /var/qmail/control/holdremote
/usr/bin/killall -HUP qmail-send
} &

The following should be added to the PPP down script, for me that is /etc/diald/ip-down:

{ echo 1 >/var/qmail/control/holdremote
chmod 644 /var/qmail/control/holdremote
/usr/bin/killall -HUP qmail-send
} &

Finally, in order to ensure that Qmail starts up in the held (offline) state, you need to add the following to the script which starts it (for me this is /etc/rc.d/init.d/sendmail.rc, in the "start" case):

echo 1 >/var/qmail/control/holdremote
chmod 644 /var/qmail/control/holdremote