Prior to today, I was maintaining all my PyBlosxom plugins by hand... which was kind of stupid, but I hadn't really gotten around to investigating better solutions.

However, that day has come! I've pulled them all into a CVS repository and set up CVSTrac to manage documentation, bugs, features, and allow people to see version history for all of them. I'm in the process of going through all the plugins, adding CVS tags, updating copyright dates, fixing documentation, adding notes in regards to where the plugin is maintained and all that.

I aim to make the end result more organized for me and users looking for plugins and also require less effort to maintain.

I merged all the changes I've made in the PYBLOSXOM_1_2 branch back into HEAD. Now I'm in HEAD and I'm going to do PyBlosxom 1.3 work until I'm ready to release. At that point, I'll make another branch for PyBlosxom 1.3 fixes and such.

I've got the following items in my todo list for PyBlosxom 1.3:

• figure out what additional variables are needed to produce RSS 2 and Atom 0.3 feeds without the rss2renderer and without additional plugins ^[1]
• add a timezone variable to the data dict
• fix bugs 1239484 and 1202107. and 1252678.
• possibly add new sample flavours: rss 0.9, rss 2.0, atom 0.3, and several html flavours ^[2]
• minor clean-up and documentation work

Why make this PyBlosxom 1.3 and not another minor 1.2 revision? Well, it has to do with the adjustments needed to fix bug 1202107. PyBlosxom checks the content-type to see if it's xml and if it is, then it escapes the $title and $body variables which drives everyone trying to do an xhtml or other xml output crazy. The only ways to fix the issue is to do a hack on the hack or introduce a backwards-incompatible change. Given that I'm more interested in the latter, I figured it's better to bump the version so that it's clearer that the user will need to make some adjustments to their PyBlosxom configuration when they upgrade.

^[1] $title_encoded, $body_encoded, rfc822 date, iso8601 date, and possibly other stuff
^[2] If you want to help with building flavours, let me know.

I implemented Matt Weber's idea to show comments when bl_type = "file" instead of depending on a "showcomments=yes" in the querystring. I didn't remove the checking for "showcomments=yes", however--I figure having both covers all our bases. This fixes the ramifications of a poor decision on my part.

I made some changes to the debug renderer to make it easier to use. It now sorts the keys for mappings and prints the keys in blue. It's much easier to read now.

I submitted a bug report on the PyBlosxom package based on an email I got from Ted from Dave from Zack. I posted a security issue on the PyBlosxom web-site to notify users. I also forwarded the issue to the pyblosxom-users mailing list. Hopefully the news will filter down to all the people that need it.

I'm going to do some more PyBlosxom work over the next week. I want to merge some functionality in from plugins into the core. I first need to merge all the changes I've done on 1.2 back into main branch. Then I'll do the work in main and create a 1.3 branch when I release 1.3. If there are any features people are itching for, now's the time to let me know. Anything I don't plan on working on, I'll toss on a web-page on the web-site so everyone can see the wishlist and the status of where things are. It's interesting to note that the wishlist and a todo list are themselves in the wishlist and todo lists.

Wow! Martin wrote up a howto for installing PyBlosxom on Debian for multiple people.

There's a series of things here I don't really know about (e.g. what kinds of things should go in /srv?). At some point, I'd like to fix PyBlosxom so it's more "standard" in terms of installation and configuration for web applications.

Here's the link for configs/pyblosxom which walks through installing a single software installation on Debian for multiple people.

Joseph pointed out a problem where IE 6 won't display a cached page when it gets a 304 from the conditionalhttp plugin. (The issue is at the bottom of the email.)

I did some poking around and discovered on Wednesday that this happens on his blog as well as on my blog with IE 6 on Windows XP. On Thursday, I was no longer able to reproduce the problem on my site, but Joseph's was still broken. I don't know off hand what changed with my site, though I did do an apt-get update Wednesday night.

Anyhow, the 304 response from my site (which seems to work fine now) is (note the server line is wrapped):

HTTP/1.1 304 Not Modified
Date: Thu, 23 Jun 2005 14:32:26 GMT
Server: Apache/1.3.33 (Debian GNU/Linux) mod_python/2.7.10 Python/2.3.4  \
        PHP/4.3.10-15 mod_ssl/2.8.22 OpenSSL/0.9.7d DAV/1.0.3
ETag: "1119536230.43"
Last-Modified: Thu, 23 Jun 2005 14:17:10 GMT
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

And from Joseph's site (which is still not working):

HTTP/1.1 304 Not Modified
Date: Thu, 23 Jun 2005 14:37:15 GMT
Server: Apache/2.0.46 (Red Hat)
Connection: Keep-Alive
Keep-Alive: timeout=5, max=100
ETag: "1118428239.0"
Vary: Accept-Encoding,User-Agent

=bunch of funky non-printable characters here=

Looking at responses from other requests to Joseph's server leads me to believe that pages are gzipped. I'm not sure if that's part of the issue or not.

My site: http://www.bluesock.org/~willg/blog/

Joseph's site: http://reagle.org/joseph/blog/

I'm running PyBlosxom 1.2.1 with the contributed plugins pack 1.2.2 with conditionalhttp. I think Joseph is as well. I have no idea if this is affecting anyone else--no one else has complained on the mailing lists or anywhere else that I've checked.

Anyone have any ideas as to what might be happening?

This is the third release of the contributed plugins pack for PyBlosxom 1.2.

Here's the list of changes between contributed pack 1.2.1 and 1.2.2:

• New CHANGELOG.txt file which describes the changes between this version and the last as well as compatability and behavior issues.
• New README.txt file which describes what's in the contributed plugins pack, where you can find it, and various other things about the contributed plugins pack.

• Matej updated genericwiki so that it works as an entryparser as well as a preformatter. Will fixed up the documentation. genericwiki was moved from the preformatter directory to the entryparser directory. Thanks Matej!

• Now has two new properites "category_start" which gets printed once before printing the category list and "category_finish" which gets printed once after printing the category list. Additionally, the default values for "category_begin" and "category_end" were fixed. This makes the default output for pycategories (x)html compliant. Thanks Joseph!

• comments no longer shows comments by default! In order to view comments for a given entry, you must append "showcomments=yes" to the querystring. THIS IS NOT A BACKWARDS-COMPATIBLE CHANGE! Thanks David!
• comments no longer has documentation for the unused comments-rejected-words property.
• comments no longer requires the email field.
• all the flavour templates for the comments plugin have been updated.
• We cleaned up the comment error messages so they're useful to the user. Thanks Nathaniel!

• w3cdate plugin now provides $w3cdate in head and foot templates. It no longer requires PyXML. Thanks to Steven and Matej!

Thanks to Steven, David, Joseph, Matej, and Nathaniel for their contributions and help.

If you find problems with contributed plugins, visit this page on how to contact us. "Problems" could be bugs, feature-requests, or setup issues.

Find the contributed plugin pack here (contrib.1.2.2.tar.gz).

This is a minor bugfix for PyBlosxom 1.2. If you use the conditionalhttp plugin, you'll want to upgrade. Otherwise, it's not crucial.

Changes:

• Fixed a problem where the blosxom renderer never c hecked to see if it had already rendered the page. This affects the conditionalhttp plugin, but not much else.
• Removed an extra filestat.
• Added a setTimeLazy method to the FileEntry class.

Doug was going to do a unit testing or a regression testing or some kind of testing system in PyBlosxom so that we'd have testing and wouldn't have to do the manual testing and the "well, gee, it must work because I don't think I did anything wrong" ^[1] type testing. But then he ran out of time or interest or something. That time period of PyBlosxom development was a little rough for all of us.

Anyhow, I bumped into this blog entry on Functional testing in Paste which at first blush looks fantastically awesome for testing PyBlosxom stuff. It's based on testing applications with Paste (Paste).

I'm tossing this in the blog in case anyone is interested in working on fleshing this possibility out or in case I discover some free time with nothing to do.

[1] I'm a huge offender of this in regards to side projects.

I'm going to try to fix a couple of issues before releasing PyBlosxom 1.2.1 and contributed plugins pack 1.2.2. The issues are as follows:

• w3cdate plugin doesn't expand "w3cdate" variable in head or foot templates (details here)
• comments plugin borks in unusual circumstances (details here)
• comments plugin requires the email field (details here)

I'm working on PyBlosxom Manual changes as well. I think it's good to add a chapter on comments and I need to flesh out the chapter on syndication, too. If anyone wants to help with the PyBlosxom Manual, let me know--I'm happy to pass off some of the writing/collection/verification work to other people.

If you find any problems with PyBlosxom 1.2 or the contributed plugins pack--let me know those issues as well.

The last couple of weeks have been really crazy. S went off to New Jersey for the weekend, so I've had a few days to work through the things in the bottomless queue of things to do. I've been making a lot of progress, but the queue is still daunting.

There were a few bugs found in the contributed plugins pack 1.2.1, so I'm going through, fixing the ones mentioned on the mailing lists and fixing some additional issues as well. I think I'll be done with the things by Monday.

In tracking down problems with conditionalhttp, I found a bug in the PyBlosxom blosxom renderer. I think it only affects conditionalhttp, but it does so in a way that makes conditionalhttp totally useless. If conditionalhttp looks at the If-Modified stuff and decides that the content has not been modified, it issues an HTTP 304... but then the renderer goes and renders all the content and sends it down the stream just as it would with an HTTP 200. Needless to say, this doesn't do much to curb bandwidth usage.

I'm hoping to fix the problem where we fetch and filestat all the blog entries multiple times in a given PyBlosxom request. It won't be the amazingly elegant fix I was hoping to do a couple of months ago--but that requires a whole lot more work and rewriting a bunch of things in a non-backwards-compatible way and thus disrupting plugins and such.

That brings me to the PyBlosxom manual work I'm doing. The manual is already 46 pages long (that include the GDFL text). I haven't covered developer topics yet--mostly I've spent my time writing and re-writing content dealing with installation, setup, configuration, flavours, plugins, static rendering, and writing entries. I'm still getting my feet wet with docbook, so that's causing it to take longer.

Manuals take a stupendous amount of time to write. Anyone who tells you otherwise is an armchair developer.

Incidentally, if you've even looked at the manual, let me know. I have no way of knowing whether I'm doing a lot of work for nothing. I'm also very interested with problems people have, portions that are vague, and any other comments. Additionally, if you want to help out, let me know.