One of the reasons I chose Blosxom was its plug-in architecture. That meant
I could start with a really simple installation, then add features as I got
more comfortable with the system. Today I wrote a plug-in for Blosxom
at work.
I’ve asked our IT department to set up intranet blogs for employees who
ask for them. I recommended Blosxom, and a virtual web server at
http://blogs.infotechfl.com to host the blogs. I want each employee’s
blog to have a URL like http://blogs.infotechfl.com/username.
One easy way to do this is to set up a separate copy of the Blosxom script
for each user, then define an Apache ScriptAlias to point to that script for
that username, as in ScriptAlias /charles /blosxom/charles. Each script
would have the correct blog_name, blog_description, and datadir for
that particular user.
Well, that was easy for me to recommend, because I’m not the one who’s
going to have to maintain the web server. Whenever there’s an update to
Blosxom, installing it would require making up to 180 copies and editing each
copy! So how about modifying Blosxom once, and have it load a unique configuration
file for each user?
And that’s when I knew I was beginning to grok Blosxom. We can install a
single unmodified copy of the Blosxom script, then install a plug-in that
will fix up the configuration information. It turns out that there’s a
registered Blosxom plug-in called
multiblosxom that does just that. But I didn’t know it, so I wrote my
own called multiuser. It’s no better than multiblosxom, but I liked
learning enough to write it myself.
I’ll write a note about how I wrote it and what I learned later tonight.
Charles Engelke's Blog 