I just updated the Taglicious plugin for WordPress to account for a change in the URL for links to delicious tags.

I suddenly noticed that my automatic link posts weren’t getting tagged in WordPress, and I simultaneously noticed that the heading for those posts had been changed to include “delicious.com”.  A quick inspection of the page source revealed the problem.  The URL for the tag links was changed from del.icio.us to delicious.com.  In fact, if you try to navigate to del.icio.us now, you get redirected to delicious.com.  The site seems to have been dressed up quite a bit of late, also.

This shows just how brittle any piece of software can be when it depends on the behavior of an outside service.  I might have had an idea this was coming if I  had subscribed to the delicious blog –  but I hadn’t even known that there was one before.  Oh well, update below.

For blog surfers who still rely on their email Inbox, the Subscribe to Comments plugin (originally by scriptygoddess, updated by Mark Jaquith) is truly a goddesssend.  Just by ticking a box, commenters can be notified by email whenever additional comments are added to a post.  But, it doesn’t notify them when comments are edited.

OK, you’re thinking “Why do I care to know when user ‘teratroll’ corrects his/her misspelling of ‘turd-for-brains’?”  Ah, but that’s not all the “edit comment” functionality can be used for.

The ever so conversational Teeni uses the “edit comment” facility to respond to comments.  She adds her response in bold right underneath the original.  While I prefer to use Brian’s Threaded Comments and take my place among all the other respondents, Teeni’s technique does feel more intimate.  The only problem with it, from a commenter perspective, is that the “Notify me of followup comments via e-mail” checkbox would notify me of all the comments except those from Teeni herself.  That is, until now.

I created the “Subscribe to Comment Edits” plugin (which you can download below) to piggyback on the “Subscribe to Comments” plugin.  It adds notification to all subscribers whenever a comment on a subscribed post is edited.  It does nothing if “Subscribe to Comments” is not activated.

Even though PHP is mostly a baling-wire and bubblegum excuse for a programming language, it does support some dynamic programming features – a couple of which can be seen in the few lines of code that comprise this plugin.  For instance, function_exists is used to determine whether the “Subscribe to Comments” plugin has been activated.  And create_function does just what its name implies — it creates an anonymous function to pass as a parameter.  That’s nice, because the anonymous function doesn’t introduce any possible name collisions — but on the other hand, if the original function had been named I wouldn’t have to duplicate it here.

I would have also made the ‘init’ function anonymous, but the escaping of quotes gets ridiculous.  That’s one case where less dynamic, more functional would be preferable.  In languages like Javascript and Ruby (and of course Lisp), you can write functions in-line wherever a datum can go, without any quoting.   But in PHP, functions aren’t really first-class objects — they’re always passed by name, and create_function returns a generated name.

Also note that the fact that $sg_subscribe is a global object (yuck) is exactly what makes it possible for me to piggyback onto its functionality without modifying the original plugin (yay).

Over on Chip’s Quips, I use the “daily blog posting” feature of del.icio.us to post links on my blog.  These posts automatically contain links to each of the del.icio.us tags that I assigned to each link.  But I also use tags in WordPress, so I wanted to have a way to combine these taxonomies (that’s a megalellenicologism for classification systems) automagically.

Hence and forthwith, I present the Taglicious plugin for WordPress (not to be confused with the taga.licio.us plugin for WordPress), which you can download below.  Whenever a post or page is saved, the content is scanned for any del.icio.us tags, and the corresponding WordPress tag is added to the post if it doesn’t already exist.  There’s also a management page in the admin panel (Manage/Taglicious) that contains a single button to update all existing posts and pages.

The regex for detecting del.icio.us tags bears some discussion.  It looks like this:

|<a href="http://del.icio.us/(\w*/)+([^"#]*)|

(using | as the delimiter to avoid having to escape /).

We look first for a link to the del.icio.us site, followed by one or more word-like URL “folders”, followed by anything up to but not including an end-quote (terminating the link) or # (which is used for specifying a starting date, etc.).  This means that any del.icio.us link will get translated into a tag, even if it is someone else’s link.  So be warned.

UPDATE (8/3/2008): Changed the URL match from del.icio.us to delicious.com.

Thanks to a suggestion from Diego, I have added tooltips to each entry in the OPML Blogroll widget for WordPress.  These tooltips display the content of the “description” attribute of each outline entry, if one exists, when the user hovers the mouse over the entry.

Note that this is not an update to the OPML Browser plugin, although I plan to add the same feature to that plugin as well (along with a ton of other enhancements).

I used JavaScript to pop up and remove the Tooltips.  I decided to roll my own (with much help from Shelley Powers’ book Adding Ajax) rather than use an existing library, in order to keep the widget lean and to avoid conflicts with other libraries that might be in use on your blog.

Thanks to Internet Explorer, this seemingly simple enhancement required about twice as much JavaScript code as as a Firefox/Opera/Safari-only version would have.  Here are the differences that required special code for IE:

1. Of course, events don’t get passed to event handlers.  So you use window.event.  No big deal.
2. And we all know about addEventListener vs. attachEvent.  Not a problem, just wrap it in a function.
3. If you attach a property to a DOM object, lose the reference, and then reacquire that same element from the DOM later, it doesn’t have the property you added any more.  Apparently IE gives you a new object each time.  So in IE, this plugin has to look up the tooltip for the current item every time it wants to be displayed.
4. Not having the “currentTarget” property on the Event object in IE really sucks.  You can use “srcElement”, but it isn’t the same element as “currentTarget”.  For instance, if you have a “mouseover” event on an element that contains a link around an image, “currentTarget” gives you the element on which the event was specified, whereas srcElement will give you whatever contained element the mouse was actually over.  So this plugin accesses parentNode until it finds the one that’s meaningful.

Another nice “feature” of Internet Explorer keeps the tooltips from displaying at all in my theme – perhaps due to the use of float on nearby div’s.  I tried the fix outlined here to no avail.  It does work using the WordPress default theme, though, so there is hope.  Let me know how it works with your theme.

I also fixed a problem with the auto-discovery link in which the ending quote on the href was missing.

Linking to earlier versions for pingback.

UPDATE: 2009-05-11: I have incorporated all the features of this widget into my OPML Browser plugin version 2.0.  Please upgrade (it’s free). 

In a recent article I wrote on [Geeks are Sexy] Technology News about the new Google Chart API, I mentioned that the only thing that’s not simple about this API is the data encoding. So, I set to work to remedy that and I whipped up the little tool you can download below to help prototype Google charts and generate the URL.

It doesn’t include all of the options in the API, but I did provide an “Additional qualifiers” field where you can append anything you want to the chart’s URL.

For now, it only supports Simple Encoding. I may add Text and Extended Encoding at some point in the future.

Next in line is to add some JavaScript to make this more interactive, as well as to wrap the Chart object in a WordPress plugin.

You can see this in action (and use it all you want) at http://chipstips.com/demo/chartmixer.php.

Tony Peak (aka Rirath) helped to identify an incompatibility with PHP version 4 in my WiPeD plugin for WordPress.  Now, if back-porting to version 4 had involved a major rewrite I would have said “Routta Ruck, Rirath” — but it turned out to be pretty easy.  I had used class constants for the values in the database fields to indicate types of entries, and class constants weren’t supported in PHP 4.  Luckily, there’s a simple replacement:  define.  So, if you want to debug WordPress on PHP 4, download version 1.2 below.

A few days ago I started reading Shelley Powers’ new book, Adding Ajax, a free copy of which Shelley generously sent me.  In the very first chapter, Shelley said something that helped me solve a nagging problem that I’ve had for months.

Readers of this blog and my other one may have noticed (and some of you have remarked) that when my sidebar length exceeded the content length, the sidebar overlapped the footer and extended into dark space.  How amateurish.  But I had spent way too many hours tweaking the HTML and CSS trying to remedy the situation, and had finally given up.  The thing is, I knew how to avoid this aberrant behavior, but not without either displaying the sidebar first or making the content section fixed-width.  What I wanted was to have the content size fluid, the sidebar size fixed, and to display the content before the sidebar (for the benefit of all readers, but especially those using a screen reader or mobile device).  So I used a large right margin on the content and applied an absolute position to the sidebar.  But with that arrangement, clear:both on the footer ignored the sidebar’s length.  For someone who cut their web teeth using tables (or dare I admit it, frames) for layout, it was enough to drive me crazy.

In Shelley’s book, she gives a very clean and simple example that applies float:left to the content and float:right to the sidebar, drawing the latter last and applying clear:both to the footer — which works fine, except that in that case a fluid content section will take up all the available space, forcing the sidebar to appear beneath it.  But Shelley hinted that this was possible with fluid layouts, and said something even more useful at the end of her example:

For additional reading on CSS layouts, search the web for “fluid fixed elastic CSS layouts”.

Now, I had previously googled until my googler was sore trying to find a solution to this problem, but I hadn’t used those exact search terms before.  Since I’m not interested in fixed or elastic layouts, I omitted those words and googled anew.  This led me to the Holy Grail of web design.  Matthew Levine explains a simple but unique approach to making fixed-width sidebars float either left or right of a fluid center section, with a footer below them all.  In brief:

1. Enclose all three sections within a container section, using position:relative and float:left to keep them from stacking vertically.
2. Apply padding to the left and right side of the container for the desired size of your sidebars.  This restricts the fluid center section to the remaining space.
3. Use negative margins on the sidebars, to move them back out over the container’s padding.
4. For the left section, specify the position.  The right section gets bumped out automatically by the size of the center section.
5. Use clear:both on the footer, to position it beneath all three sections.

Since I don’t have a left sidebar, I was able to do this even more simply:

1. Enclose the content and sidebar sections within a container section, using position:relative and float:left.
2. Apply padding to the right side of the container for the space to reserve for the sidebar.
3. Use a negative right margin on the sidebar.
4. Apply clear:both to the footer.

Naturally, this didn’t work the first time (when does it ever?) — I had issues with inherited padding, prematurely closed div’s, and other such nonsense that had accumulated like dust in my theme files over the course of many tweaks.  These were relatively easy to hunt down using the Web Developer toolbar for Firefox (which Shelley also recommends in her book), using the Display Block Size and Display Div Order options on the Information menu.  One issue that I suspect would have taken me much longer to hunt down had it not been for this feature was a conflict between div class names — my theme used “content” for the class of the main content section, and the Brian’s Threaded Comments plugin uses the same class name for the section that includes the contents of each comment.  So when I added float:left to ”.content”, the comments section went haywire.  That’s a good example of why, when writing a plugin, you shouldn’t use common class names or ids for elements it produces — you should always prefix them with something to make them unique, because you never know who else might be using that name as well.  To work around it, I just renamed my “content” class to “blogcontent”.

Over the years, I’ve learned CSS and Javascript on an “as needed” basis.  Shelley’s book seems well targeted for an audience of people like me, because it’s all about bringing existing sites forward to these newer approaches.  I’m sure that it will fill in some gaps for me — and that this won’t be the last solution that gets sparked from reading her pages.

So I was coding along one fine day, happily using my WiPeD debugger for WordPress, when I suddenly stumbled on a problem with it.  I was attempting to debug a function that was hooked to an action that was supposed to be triggered by the MetaWebLog API (‘save_post’, when posting from a blog authoring tool), and none of my debug messages were being displayed!  Suddenly the heel of my hand went *bonk* on my forehead — of course I couldn’t retrieve any messages from XMLRPC processing, because I was saving the messages in a session variable, and the client in that case is my authoring tool instead of my browser – so the sessions aren’t the same.  Duh, time to rethink.

The downloadable version below saves the debug messages to the database instead of to a session variable.  Obviously, that means that multiple users will mix their output in the log.  Of course, you’d expect to be debugging on a private site, but just in case I added an options page where you can exclude users based on their capabilities — with the default being ‘level_9′ (administrators only).  I also added options to allow you to customize when the debug log is displayed, as well as when it’s cleared.  Spin it up, and check out the Readme-WiPeD.txt file.

UPDATE: get the latest version here.

Shack Dougall spotted several HTML coding errors in the latest verion of my OPML Browser plugin.  Get the version 1.3 below.

Pingbacks to previous posts.

Speaking of the deficiencies of PHP, another one is the complete lack of built-in debugging capabilities.  Sure, you can find debuggers for PHP, if you’ve got the time and ability to configure them on your server.  I guess if I was really serious about PHP I’d have to get one of those, but so far I only use PHP for WordPress customization, so it hardly seems worth the effort.

Some people will tell you that you shouldn’t need a debugger.  That it’s a sign of lazy programming.  But PHP has so many pitfalls, and WordPress has so many actions and interactions between plugins and themes provided by so many different developers, that I think you’re excused if you need a little help figuring out just what the heck is going on in your code.

When writing a plugin or modifying a theme for WordPress, usually all I need to know is the order of events and the values in various variables.  Sometimes you can get away with inserting “echo” statements in your code — but sometimes you can’t, like when your code executes ahead of a “wp_head” action that wants to add headers.  Besides, randomly placed “echo” statements can easily get lost from view in the whirl of words and images that comprise your theme and content.

So, I developed a simple little plugin that collects debug statements and prints them out nicely above the footer of your theme, or below the admin footer, whichever gets executed first.  I call it WiPeD, for “WordPress Printf Debugger”.  Anywhere in your code, you can call WPD_print() and pass it whatever text you want to output.  The lines of text are aggregated in a session variable until they are output together (in separate divs, surrounded by a single containing div).  Thus you can use styling to set the messages off from the rest of your blog, if you desire.

Here’s an example, from a project I’m currently working on.  My plugin was producing no results, and I couldn’t figure out why.  So I added some calls to WPD_print():

Then, when I executed the code to trigger this action, here’s what I saw at the bottom of my page:

That tells me that I got into my function and passed the tests, but the post has no content at that point.  Now I just need to figure out why.

See the enclosed readme file for more details.  Have fun debugging your PHP!

UPDATE: get an updated version here.

Version 1.2 of the OPML Browser plugin for WordPress has just been released!  This version includes some significant upgrades, including:

1. You may now have up to 9 opml-browser widgets. When upgrading, the options from your existing opml-browser widget are copied to the first opml-browser widget.  Thanks to Mark Barnes for suggesting this enhancement.
2. The option to exclude your domain now ignores differences in case when comparing domain names.  Thanks to Tony Lindskog for finding that one.
3. You can now override the title for the OPML link by entering text into the “OPML title override” field.  I didn’t want mine to read “FeedDemon Subscriptions”, so I added that for myself.
4. Added the ability to embed the browser within a page or post using a special [ opml-browser ] element in the text.  See the readme.
5. Added a “Get this widget” link at the bottom of the widget.  Thanks to TDavid for suggesting that little bit of self-promotion.

Download version 1.2 via the button below.  Pinging back to all previous posts for those following comments.

UPDATE: More corrections here.

Since I haven’t heard from Jerome in quite a while, I took it upon myself to fix a couple of nagging problems in the Jerome’s Keywords plugin for WordPress:

1. When editing, moderating, or deleting comments, the tags on the post get deleted.
2. Some users get a nasty duplicate alias SQL error due to the combination of other plugins with JK.

The download below should fix both of those.  If/when Jerome incorporates these fixes into his next version, I’ll take down this copy and point to him instead.

In the first case, I removed the action hook for ‘edit_post’.  This gets triggered when the comment count changes, and the action for it deletes all tags and re-adds them from the request.  Unfortunately, if the request doesn’t contain any tags (as in the case with editing comments) you lose your tags.  It turns out that the ‘save_post’ and ‘publish_post’ actions are sufficient for handling cases where you can edit the tags.

In the second case, it seems that the ‘posts_join’ action gets triggered more than once.  So I changed this action to build the join clause we need in a separate variable, then make sure it doesn’t already exist in $join before appending it. I made a similar change to posts_where as well.

UPDATE 9-17-2006: Found a bug in my correction for the duplicate alias error, and applied the changes to the beta 3 version.

Happy tagging!

Call me clueless, but I did not know until I found out from Jenn that the <FONT> element has been deprecated and will not validate XHTML 1.0 strict DTD.  The keywords-tagcloud widget for WordPress uses that element with a SIZE attribute to scale the tags in the cloud (extends wrists, awaiting slap).

Far be it from me to fly in the face of progressing standards, so I have just released version 2.3 of the keywords-tagcloud widget that uses a STYLE element specifying font-size instead.  You can get it by pressing the button below.

Besides averting a visit from the W3C police, using the font-size style provides much more flexibility on how the font is, um, sized.  You got pixels, percentage, etc. to choose from.  So I added a field to the widget’s control panel where you can specify what units to use.  The scaling maximum/minimum fields in Options/Jerome’s Keywords/Tag Cloud Display can be used to control the range of units to apply.  Unfortunately, these values get rounded down to the nearest integer, so “em” doesn’t work well for units.  Also, CSS units don’t provide an exact mapping for the old font size attribute, but “ex” is pretty close, so I made that the default.  However, I found that “%” with a range of 70-250 looks nicer for my theme, and you can see that on the right sidebar here.

If you do your own styling of the widget, make sure you read the upgrade notes.

Thanks, and keep on tagging!

Pingback to all previous posts on this subject for the sake of those who subscribe to comments.

Well, the OPML Browser plugin for WordPress has only been released for two days and already we’re up to version 1.1. Hopefully this one will last a while longer.

I added a new feature: start with all folders closed. Selecting this option will display the browser with all categories collapsed initially, unless the browser doesn’t support Javascript (otherwise the user wouldn’t be able to open them!).

I also completely reworked the code, using a class for the rendering engine. That allowed me to eliminate all global variables (almost always a good thing) and reduce the number of parameters being passed around. I still say PHP’s object syntax sucks, but it’s a good bit better than what I had before.

I even added some comments.

Let me know how you like it.

UPDATE: Get the latest version here.

Since I first released the OPML Blogroll widget, I’ve received numerous suggestions for enhancements. One that keeps coming up is the ability to show the hierarchy within the OPML file — categories, if you will.

Because of the way the original widget parses and displays the outline, this request was incompatible with the existing code. So I developed a new widget/plugin that does keep the hierarchy intact, and you can download it below. It also uses javascript to expand/collapse categories when the associated folder icon is clicked.

The code also includes an API for displaying an OPML browser within PHP code, so you don’t have to use the widget if your theme is not widget-compatible, or you want to display the browser somewhere else.

See the opml-browser-readme.txt file included in the download for full documentation and tips on how you can control the display through CSS styling to achieve some of the other suggested enhancements — such as scrolling within a limited height, bolding the categories, and removing the ability to expand/collapse categories.

There’s still one thing I haven’t figured out how to do, though. If the text of an item wraps, it wraps beneath the feed icon to the left. I’d like to be able to make it line up with the first line of text, but I’m not enough of a CSS wizard to manage that yet. Any suggestions?

UPDATE: Corrected a missing end-quote error in the autodiscovery link at 14:02 3-29-07

UPDATE: Get the latest version here.

Sorry Paul, this isn’t the big update you’re waiting for — just a few loose screws that needed tightening up.

After upgrading to WordPress 2.1, I noticed that the RSS icons in my OPML blogroll widget disappeared. I was using an image that is no longer distributed in the same location, so I put a copy of rss.png in the wp-content/widgets/images directory.

Taking a look at how I was referencing images, I realized that it also wouldn’t work if your blog was not in the root folder of your domain. So I added a call to get_settings(‘siteurl’) to fix that up.

Last month I nearly ran out of bandwidth on Chip’s Quips, and after analyzing the requests I found that nearly half of the bandwidth for the month was consumed by requests for my OPML file. In my case, the OPML file resides on the same server as my site, so there’s no need to request it over HTTP. I added a “Local path” option to the widget which, if specified, will open the file locally.

So now of course the “OPML URL” option is no longer required. If you leave that empty, then the auto-discovery link will be suppressed. It doesn’t make much sense to auto-discover a link on the local file system.

I also discovered that WordPress’s cache support in wp-includes/cache.php ignores the $expire parameter that you can pass when adding or setting cache data. This has not been fixed in WordPress 2.1 either. I’ll have to come up with a better solution so the OPML file doesn’t get banged every fifteen minutes, whether or not it’s on a local drive. But we’ll leave that for the next revision.

UPDATE (3/29/07): Tony Lindskog found a bug where a feed that has no “text” attribute caused a regular expression parsing error, and Paul McGillivary found a missing end-quote in the auto-discovery link. I’ve included fixes for those as well.

UPDATE (3/29/07): For an OPML plugin that preserves the hierarchy within the OPML file (categories, usually) and lets you expand/collapse that hierarchy, go here.

UPDATE (4/17/08): The latest version of this plugin can be found here.

UPDATE: WordPress 2.2 stuffs this approach. But fear not, there is yet a far, far better way of doing this. Download and activate the FeedBurner FeedSmith plugin – it’s automagic!

For a while now I’ve been redirecting my WordPress feeds through FeedBurner using a content pumping hack. That approach has the advantage of maintaining the standard feed URLs for WordPress, but it does place a little more burden on my server. After changing servers, I discovered another disadvantage: for some reason FeedBurner suddenly stopped distinguishing individual visitors. I’m guessing it’s a change to the way fopen works on a URL between versions of PHP.

Then yesterday, Randy invited me to join the KBCafe FeedBurner network. While doing so, I also decided to join the FeedBurner Ad Network. Somehow, I don’t think feed advertisers would be exactly chomping at the bit to place ads in a feed with only four subscribers, three of them bots. Time to fix this.

The right way

Instead of regurgitating content, you can just return a header to redirect the client. If you haven’t already, rename wp-rss2.php in your root directory to wp-rss2-fb.php. Burn a feed in FeedBurner, using that page as the feed source. Now create a new wp-rss2.php that contains only:

<?php
header( 'Location: http://feeds.feedburner.com/ChipsTips');
?>

Replace “ChipsTips” in the URL with your FeedBurner feed name. This performs a temporary redirect, so your feed’s URL remains the same in all clients, they just always get redirected to FeedBurner. If you want to save yourself some traffic, you can use a permanent redirect instead:

<?php
header( 'Location: http://feeds.feedburner.com/ChipsTips', TRUE, 301);
?>

The 301 response code directs the client to permanently change the URL for this resource, which loses the advantage of keeping the standard WordPress URL. What if you decide to leave FeedBurner? Won’t you lose all your subscribers? Well, it turns out that FeedBurner will return the favor and permanently redirect your feed for 30 days if you unsubscribe. Randy says he’s tested it. So I decided to permanently redirect, hoping to improve throughput for both my feeds and my sites.

Next, make the same change to your ATOM (wp-atom.php), RSS 0.92 (wp-rss.php) and RDF 1.0 (wp-rdf.php) feeds. I decided to redirect all of these to my RSS 2.0 feed in FeedBurner, and then use FeedBurner’s SmartFeed service to convert to other formats as needed. That allows me to aggregate my FeedBurner stats.

And speaking of stats, after FeedBurner had a chance to collect them correctly for a day, I found that even before my move it had failed to disambiguate quite a few subscribers. I have more than twice as many subs as I had thought! Thanks to all of you!

Aoyoyo reported an error in my keywords-tagcloud widget for WordPress. That widget requires Jerome’s Keywords version 2.0 to be installed and activated. Lazy me, I wasn’t checking for the opposite case, which results in a “Fatal error: Call to a member function on a non-object”. Here are my wrists. Slap ‘em hard.

Version 2.2 (download below) corrects this problem. If Jerome’s Keywords 2.0 is not activated, you now get a warning message displayed in the Presentation admin panel for the widget and also in place of the tag cloud display.

Version 2.0 of Jerome’s Keywords wraps the plugin’s API in a global object. If the plugin isn’t activated, the global is null. So, I only needed to add a simple test for is_object($JKeywords) to respond appropriately, instead of spilling my guts on your blog.

UPDATE: new version with improved font sizing here

Version 2.1, for use with Jerome’s Keywords plugin version 2.

I’ve been putting off updating the tag cloud widget for some time, because Jerome had indicated that he would include it in his plugin in a future version. That hasn’t happened yet, so I wanted to add a couple of new features now:

1. You can now control the expiration of the cached display. It still defaults to 900 seconds, but you can alter it to be anything you wish.
2. Besides releasing the cache when the widget controls are updated, it also releases the cache when a post is edited, saved, or published.

Please let me know if you experience any difficulties, or if you have suggestions for further enhancements.

Happy tagging!

UPDATE: added error check for when Jerome’s Keywords 2.0 is not activated. Get the latest version here.

Thanks to some suggestions from Sergio Longoni, this morning I whipped up version 1.1 of the opml-blogroll widget for WordPress.

New features include:

• OPML auto-discovery link tag added to the “head” section of your page automatically (Sergio provided the code).
• You can suppress the OPML image and link by unchecking a new option “Link to OPML?” which is checked by default when upgrading.
• If you keep the OPML link, I’ve added the new semi-standard OPML icon.
• Closed the “img” tag for the RSS icons for XHTML compliance (oops).

Suggestions for future enhancements:

• Sergio suggested adding more control over how items are displayed. For instance, he would prefer “li” tags instead of a table. I’m going to give that some thought, but perhaps I could include options for prolog, epilog, pre-item, post-item, etc. and let you control the HTML.
• The Dead 2.0 skeptic (who appears to have been hammered out of the blogosphere by the traffic surge incumbent upon his identity intrigue) suggested a while ago that I add some form of paging, so that only the first N items would be displayed unless the user took some action.

What do you think of these suggestions? Got any more?

UPDATE: Latest version here.