jclark.org/weblog

Home Sweet Homepage

This website finally has a homepage. Previously, http://jclark.org displayed only a “comming soon” message. I had planned to setup Apache to use 304 redirects to send such traffic straight to the weblog. Upon further consideration, I decided that it was better to allow search engines to index a home page as well as the weblog… after all, the weblog is at /weblog and not / just incase I ever want other content on my home page.

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 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.

Well Fed

The RSS Feed for this weblog has been updated to RSS2.0. I‘m currently using a shortened , and including the full text as . It’s valid,
but my current aggregator (NetNewsWire Lite) is only showing the short description. I’d like to try NewsMonster, but the OS X version is not ready.

Feed & Validation badges and links added to the right hand area of the page… which needs a name. It’s more than just a navbar. Suggestions welcome.

Uncommonly Good

This weblog is now published under a Creative Commons Attribution-ShareAlike Licence. Badge and link added to the right hand side of the page; auto-discovery RDF included in the XHTML source.

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 $var>?> and !$var>?> 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.