Using xhtml:body in RSS feeds via Blosxom

As I mentioned previously, I’ve recently begun using the full version of NetNewsWire, which honors the use of xhtml:body within an RSS feed. When I upgraded my feed to RSS 2.0 a while ago, I decided to include a forshortend version of the story in the RSS tag, and the full, xhtml content of the story within . Since I had been using NetNewsWire Lite, I could only see the short description.

When I loaded feed into NetNewsWire, I found to my horror that all of the xhtml tags were being escaped within my xhtml:body. I looked at my RSS flavour’s story template, and my html flavour’s story template. Both use $body to include the body of a post. But my html pages don’t have all of the tags escaped.

It turns out that blosxom.cgi is the culprit… it includes logic to escape less-thans and ampersands within storys if the output mime type includes ‘xml’. This isn’t exactly a bug… arbitrary xml (or html) tags within the larger RSS xml document could cause the RSS file not to be well-formed, and so to not parse with standard XML tools. However, since my content is all valid xhtml, and is being enclosed within the feed inside an xhtml:body, there’s no need for this escaping.

I patched my blosxom.cgi in the manner I would expect the change to be made to the official blosxom.cgi… as a configurable option. The changes are as follows.

1. Add a new config variable
2. Add it to the vars declaration
3. Change the code to check this variable.

In more detail:

Step 1: In the ‘Configuration Variables’ section at the top of the file, add a config var.

 #set to 1 if RSS template wraps $body in 
$rssxhtml = 1;

Step 2: Find the ‘use vars’ section right below the configuration varibales. Add $rssxhtml to the list of variables between the !’s.

Step 3: Update the code. Look for this block of code (try searching for ‘xml’:

      if ($contenttype =~ m{\Wxml$}) {
        # Escape <, >, and &, and to produce valid RSS
        my %escape = (’<’=>’<’, ‘>’=>’>', ‘&’=>’&’, ‘”‘=>’”‘);
        my $escapere  = join ‘|’ => keys %escape;
        $title =~ s/($escapere)/$escape{$1}/g;
        $body =~ s/($escapere)/$escape{$1}/g;
      }

And change the first line to look like this:

      if (!$rssxhtml and $contenttype =~ m{\Wxml$}) {

I’m going to submit this to the list and see if Rael will incorporate it into blosxom.cgi.

On Editing Online

I author (and edit) my blog entries using the wikieditish plugin for Blosxom. I write nearly all of my content using the textile plugin. While this arrangement works, it isn’t perfect. For example, to show an example xml , I have to escape the < character as & lt; xml /> in the editor. If I need to edit the entry after it is posted, however, encoded characters are unencoded in the textarea of the edit form. This means I have to remember to re-encode such things.

This, and other desired features, is leading me to consider building a new editing plugin for Blosxom. Features I want:

• Play nice with other plugins, such as textile, wikiwordish, smartypants, others

• render exactly what’s in the disk file to the edit box, handling escaping on the way.

• option (checkbox, metatag?) to mark article as being interpolate-fancy exempt; causes auto-escaping of <'s, making it easier to post sample xml text, etc.

• Preview feature. Saves post with alternate extension, then runs the article through Blosxom in some way that recongnizes the extention, letting you see the post in context of your flavour template(s), without posting to the world; while viewing you can return to re-edit or elect to post. This means seeing content via your standard template, PLUS seeing some kind of editing interface. Perhaps a popup, or frame, or maybe edit plugin fiddles your flavour template directly?

• Checkboxes (maybe even backed by server- or client-cookie- based preferences) for auto-inserting commonly used meta-tags like meta-markup:textile.

• This may just be a matter of flavor templating the editing form (a la wikieditish), but I want to see hints for the plugins I use, like textile, etc.

• more secure passwording than wikieditish

• would-be-nice-needs-more-thought: ability to accept posts
  via the nAtom API

I’m just pushing the thoughts around inside my head at the moment. If you have additional features you’d like to see in an editing plugin, click the comment link below.

Storystate 0+1i

My very first published plugin for Blosxom. You can download it here.

Storystate provides a number of convenience variables for use with the interpolate_fancy plugin by Blosxom author Rael Dornfest. It was designed to be especially useful with writeback. Storystate also allows presence of a meta-writeback tag to control if writebacks are open or closed. It’s basically useless without interpolate_fancy.

NOTE: best if used with interpolate_fancy version 2003-09-07 or later.

Excerpt from the POD docs:

Just drop it in your $plugin_dir. Optionally, you can adjust the values of the configuration variables at the top of the file. There are covered later.

Most of the variables are simple boolean indicators, using undef for false. This allows them to be used with interpolate_fancy’s and constructs. Some variables are story specific, (updated for each story), while others are based on the request url and are valid in the head and foot as well.

The request flag variables are:

• $permalink true if request url is a subdir permalink, e.g. /this/that/story.html
• $datepermalink true if request url is a date permalink, e.g. /2003/09/07/story.html
• $anypermalink true if request url is either of above
• $blogroot true if request is for blog’s root e.g. / or /index.html
• $archive true if request if date style, e.g. /2003/09
• $category true if request is subdir style, e.g. /this/that

The story-specific flag variables are:

• $writeback_closed true if writebacks are closed for story (see below)
• $permalink_wbopen true if !$writeback_closed and $permalink
• $permalink_wbclosed true if $writeback_closed and $permalink

The idea of closing writebacks is that you are no longer accepting comments for a given story. Just add meta-writeback: on or meta-writeback: off to the header of the story. If no meta-writeback header is found, the value of the config variable $writeback_default is used instead. Values are on (writebacks open) and off (writebacks closed). This is of course dependant upon you implementing checks against these variables in our story template, see the example below.

There is also a story-specific text variable:

• $writeback_message description of writeback state for story

This is useful for links to your writeback page. It returns (by default):

• ‘Add the first comment’ If writebacks are open for story and no comments exist
• ‘No Comments’ if writebacks are close and no comments exist
• ‘1 comment’ if only one comment
• ‘n comments’ if >1 comment, n=$writeback::count

These messages are configurable, see the config variables at the top of the file, they are documented inline.

See the POD docs for an example of usage, I just can’t get sample HTML to play nice with Textile2.

Fancy-Shmancy

A big part of my new design is the use a new Blosxom plugin, interpolate_fancy. This plugin, by Blosxom author Rael Dornfest, replaces the default Blosxom interpolation routine with a much more powerful version, allowing many forms of conditionals in addition to straight variable substitution. It also changes the interpolation syntax from a perl-style $var to an XML-like .

The POD documentation for interpolate fancy lists all of the valid syntactical forms, including:

* Unconditionally and recursively (backward compatibility with Blosxom’s standard interpolation)

e.g. include a link to the story’s path using various template variables.

$path

However, this functionality is not implemented. Instead, I converted my templates to the new format. However, my RSS feed uses the flavour templates built into Blosxom (with a couple of tweaks). This flavour, just like the built in .html flavour, use the original interpolation syntax. The net result of which is that my rss feed is broken.

For now, I will make a standalone RSS flavour, to get the feed working again. I will also post this issue to the mailing list, and see if interpolate_fancy should change.

UPDATE: The rss feed is working again. Instead of implementing the built in flavours as external flavours, I enhanced interpolate_fancy to contain updated versions of blosxom’s built-in templates. I’ll post my version here a little later.

This is a test…

This is a test of a new plugin for blosxom. More info to follow.

Update At least this used to be. Now it’s my testing sandbox. Never know what you might see.

Iñtërnâtiônàlizætiøn

Irony

While writing the previous entry, I used Textile’s footnote feature to note that my site’s RSS feed validates. I even made the word “validate” a hyperlink to the Feed Validator with an url that will autocheck my feed. Since I always check my links as soon as I post a story, I clicked the validator link. Only to find that my feed no longer validates.

Why does my feed no longer validate? Because of the footnote. Specifically, because Textile’s footnote feature makes relative url hyperlinks to anchors within the page. And relative urls are not valid in the element.

My feed will remain invalid for a short period of time while I ponder a solution. So far my options seem to be:

1. Remove the footnotes
2. Live with a non-validating feed
3. Tinker with the textile2 plugin and/or textile.pm, and get it to emit full (not relative) URLs for footnotes.
4. Tinker with the RSS flavour to fix up such urls automagically.
5. Find/build a plugin that rewrites all relative urls to fixed urls. This will be tricky for the RSS feed, since the url is not relative to the feed being created.

Option 1 is admitting defeat, and besides, I like the footnotes. Option 2 I will accept only as temporary, to keep from having to take down the offending post. Options 3, 4, and 5 mean learning more about Blosxom’s plugin model, and/or the guts of textile; both things are already on my mental list of Todo’s. I’ll post the resolution when I find it.

UTF-8 Madness

One of my stated goals with this weblog is to better learn web standards, such as XHTML and CSS. So each time I make a change to the design, or post a new story, I use the validation badges (see the right hand column) to check that everything is still copascetic. Yesterday, it was not.

The error message from the XHTML validator, in all its yellow-highlighted glory, was:

Sorry, I am unable to validate this document because on lines 52, 56-58, 62-66, 68-70, 73, 76-81, 83-84, 86 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.

Now, this is clear (invalid characters), and yet not so helpful (what characters? Where in the line?) I didn’t see anything in the view source, or opening the original file in an wikieditish. And of course, I’m using textile, so that could be a culprit as well.

After some experimentation (by which I mean to say, several hours of searching Google, threatening the Validator, and banging my head against the wall), I found that by saving the XHTML from my browser, and running it through less, I could see the bad characters. They were all 0xA0, which is 160 decimal, a.k.a.  . Of course,   is valid in XHTML, as is  . But utf-8 does not encode single byte values above 0×7F as single byte values, so 0xA0 is not the utf-8 encoding for nbsp.

The thing is, I’m not sure how they got there. The seemed to mostly appear inside blocks, in place of the original indent spacing. So I suspect it was a combination of textile2 trying to format the code, and wikieditish saving the document. I'm going to have to do some experimenting to make sure I understand how they interact.

$_ = $body;
s/\xA0/ /;  #non-breaking space


snip!  more translations in here,

like emdash, soft hyphen, etc.

$body = $_;