When we last left our valiant plugin, it had just succeeded in implementing all of the features requested by László Monda, except for one: László wanted to be able to use the rss.png from /wp-includes/images to avoid an extra GET request when loading the page. Although I had provided a way to override the location for the images, he didn’t want to put all of the images in /wp-includes/images, because that directory gets overwritten by upgrades to WordPress. He resorted to making a one-line custom modification to the code.

Well, I hate forcing people to patch my code for the functionality they desire. I can also see his point. Although the overhead of a single GET does not concern me much, I imagine in bandwidth-restricted circumstances every little bit helps. On the other hand, I don’t want to hard-code the location of this image, because existing users may be customizing the images used for the opml-browser plugin. So, I implemented László’s change as an option: the “Monda option” — or more verbosely, “Use rss.png from wp-includes/images?” This option overrides the “Image URL” option for rss.png only.

This one change accompanies a bump to version 2.4. Download links below.

Oh, and if you’re wondering about the word “legendary” in the title of this post, just ask Google a mindent tudni.

I never seem to be able to stick my fingers in a WordPress plugin without getting them nasty. After I released version 2.2 of the OPML Browser, László came up with several more suggestions. I didn’t agree to all of them, but here are the ones I’ve included in version 2.3:

• Added option for “Show clickable folders for categories”, with a default value of true. You can now uncheck this option to suppress the folder icons. Of course, if you do that, the user cannot collapse categories.
• Escape any special HTML characters found in the text, title, description, xmlUrl, or htmlUrl attributes, but without double-escaping.
• Changed img tags to use the “id” attribute instead of the obsolete “name” attribute.

The last two items allow the widget to validate cleanly at html5.validator.nu.

I shall now go wash the PHP off my hands.

A user (I have users?!?) named László Monda offered some enhancement suggestions for my OPML Browser plugin for WordPress. I have implemented them in version 2.2, which you can download from the links below.

Specifically, I added the following options:

• Image URL, defaulting to the previous hard-coded location (images subdirectory). László wanted to be able to reuse the rss.png in the /wp-content/images directory instead of loading two RSS icons. He can do that now by changing the “Image URL” in the widget options to that directory and making sure that all of the needed images are located there.
• Include OPML descriptions as tooltips, with a default value of true. If you uncheck this option, then no tooltips will be displayed. I also added a delay of one second between the mouseover and the tooltip display.
• Include “Get this widget” link?, with a default value of true. If you uncheck this option, the link will not be displayed and you must either plaster my praises all over your blog or reconcile your conscience to your ingratitude in some other way.

I also took this opportunity to move the OPML Browser project into a Mercurial repository on BitBucket, and to offer a .tar.bz2 download in addition to a .zip format. Enjoy!

Sam Mela liked my WiPeD debugger for WordPress, but he wanted an easy way to include call traceback information.  So he added it, and he kindly shared his addition with me.

I’ve adapted what he did to my own tastes and included it in the download below.  Whenever you want to add the current call stack to the debug log, just call:

WPD_backtrace();

In order to test this, I added a new option in the Options page:

Trace the following actions (comma-separated)

Just enter the name of any action hooks on which you want to get a traceback added to the debug log.  This is not only useful for testing the plugin, it can also be used to find out where in the twisty little passages of WordPress each of the actions gets invoked.

Largely because of this feature, I now initialize this plugin whenever it is activated.  Previously I delayed setting it up until WPD_print was invoked.  So this plugin now imposes a small overhead if it is activated and not used.  Be advised.

I also adopted Sam’s idea of providing default styling (which I modified significantly).  If you don’t like it, you can remove or modify WiPeD.css.

On this site I write examples in a variety of programming languages.  I’m sure that some of my WordPress (PHP) audience gets tired of hearing about Synergy/DE, Ruby, and C#.  Some Rubyist readers have commented that I should stick to writing about Ruby.  I experienced a wave of subscriptions from Lispers when I posted twice about Lisp, but they’re probably sick of all the non-Lisp posts I’ve written since then.  So, it’s time to give subscribers more choice.

Take a look over at the right sidebar (here, if you’re in a feed reader).  Scroll down below the ads and notice the new “Categories” widget.  You can now subscribe to any category by clicking the orange RSS icon beside its name.  Categories that contain other categories also include their content in the feed.  So, you can subscribe to specific programming languages, or the “WordPress” feed, or the “.NET” feed, or the “OPML” feed – depending on what you’re interested in reading.  Note that I often post under more than one category, so for instance if you subscribe to “PHP” you’ll get a superset of “WordPress” — because all WordPress posts are also under PHP – at least, so far.

How you, too, can display this glorious new Categories widget on your site

Surprise!  It’s really my trusty OPML Browser widget.  But it’s feeding from an OPML file that is automatically updated by a new WordPress plugin that you can download below.  This plugin generates an OPML file containing links to your categories and their feeds.  You can override the feed URLs (in case you want to feed them through FeedBurner), or let the plugin use the default feed URL.  You can generate the file on demand, but the plugin will automatically regenerate it any time you add, change, or delete a category.

Once you’ve got the Categories OPML plugin all set up, just add the OPML Browser widget to your sidebar and tell it where the file is located.  Make sure you have the latest version of the OPML Browser – the OPML for hierarchical categories posed a few challenges for the older version and required an update.

I thought of a new use for my OPML Browser plugin, but the OPML file I intended to use with it threw me a couple of curve balls.

First of all, the file contained nested outline elements, with xmlURL attributes on the containing elements.  Until now, I displayed the feed icon if an item had a feed, and only displayed the folder icon if it didn’t (and it had child elements).  Because the only way to expand/collapse the tree is by clicking on the folder icon, I’ve changed this to display both icons in that case.

Second, my file nests the outline tags more than two levels deep.  I was using preg_match to parse the XML, with a non-greedy search for the end tag.  Can you guess what the problem was with that approach?  I’d get the end tag for an internal outline item when I was looking for the end of the outer item.  This only happened, of course, when an inner item was terminated by </outline>.

Rather than trying to get even fancier with my regular expressions, I decided to implement a real XML parser instead.  I took a look at SimpleXML, but it requires PHP5 and allow_fopen_url.  Then I looked at PHP’s built-in XML parser functions, but that’s event-based and I needed to wade through the document on my own terms.  So I implemented my own simple XML DOM parser, and included that with the plugin.

Yes, this is such a major upgrade to my OPML Browser plugin for WordPress that it warrants bumping the initial digit in the version number.  Here’s what changed:

1. The plugin now expects to be installed in its own folder: (siteurl)/wp-content/plugins/opml-browser
2. JavaScript and CSS have been separated into their own files.
3. JavaScript events are now hooked on window load instead of in the HTML.
4. Added “alt” attribute to all “img” tags.
5. Images are now looked for in (siteurl)/wp-content/plugins/opml-browser/images
6. If an image cannot be found, it will be replaced by the supplied unknown.png (a question mark).
7. Added “Sort items?” option.  This sorts within categories, unless the “flatten” option is enabled (see next item).
8. Added the “Flatten hierarchy?” option.  This combines all items into one level.  If sorting, all items get sorted together.
9. The OPML description attribute is now displayed as a tooltip (as in the OPML Blogroll widget, but it also works in IE and Opera now!).

As far as I know, the OPML Browser can now do everything that the OPML Blogroll widget could do (items 7 through 9 filled that out), so I am herewith declaring the OPML Blogroll widget retired from further upgrades.  Please use this plugin’s widget instead from now on.  Let me know if I’ve forgotten any functionality that you need.

A big “thank you” to all of my users who requested various features and reported bugs.  This plugin would not be what it is today without your input. 

I made the classic web developer mistake:   “It’s just a simple change, what could possibly go wrong?”  So I didn’t test it thoroughly before launching it on my unsuspecting readers.

For about a day, the “Add comment” button on posts here and at Chip’s Quips and Camden Software would only work if you were already subscribed to email notifications for the post in question.  My sin was particularly egregious, because you would only discover the impotence of that button after you’d already typed in your masterfully crafted response and were ready to submit it.  Shame on me.

Details:  I added a feature to allow you to subscribe to email notifications without leaving a comment, using a function that comes built into the Subscribe to Comments plugin for WordPress.  That function creates the necessary form for submitting those subscriptions, and I inadvertently placed it within the <form> tags for the comment form (thanks to the exceptionally cluttered version of comments.php that comes with the Brian’s Threaded Comments plugin).  When a form contains another form, the JavaScript method “submit” does not exist for that element, and that’s what the “Add comment” button calls when clicked.  I found my error using the very handy JavaScript debugger in Google Chrome.

But it’s all right now (in fact it’s a gas).  I also modified the comment form such that the email subscription checkbox is now in the tabbing order.  The Subscribe to Comments plugin adds this checkbox, but does not specify a “tabindex” attribute.  So I hacked my copy of the plugin and my copy of the comments.php that comes with Brian’s Threaded Comments to move this checkbox to before the “Add comment” button, both visually and in the tabbing order.  Thanks to apotheon for complaining about this, or I would never have noticed (being the author of each post, I never see the checkbox).  I left a comment on the Subscribe to Comments home page requesting the ability to specify a tabindex for the checkbox, but in the mean time I’m posting my modified version here, along with my modified comments.php.

Last year I changed the theme on this blog and my other ones to make use of Matthew Levine’s Holy Grail approach to layout – or rather,  a simplified version of it, since I only need two columns.  My motivation for doing this was to render the content before the sidebar (for impatient and mobile users, as well as for SEO), yet have the fixed-width sidebar float on the right and leave the remaining space to the content.  Although simplified for two divs instead of three, wedging it into an existing style sheet was anything but simple.  I wrestled with padding and margins until I got it working for Firefox and IE7.  In Opera and Safari, the sidebar kept popping out below the content, and (with apologies to their users) I didn’t care enough about those browsers to spend any more time trying to remedy this mostly cosmetic issue.

Enter Chrome.  It’s such a fast browser that I decided to start using it as my default for a while.  Of course, it uses WebKit for rendering, same as Safari — so sure enough, my sites had the same bug, only you’d see it faster.  I decided it was time to do something about my problem.

One of the reasons why I never figured out what was going on in Opera or Safari is the dearth of web debugging tools available for those browsers.  Chrome adds a JavaScript console that also shows you the dimensions of the sections and what styles actually get applied to them.  Turns out, though, that confusion over CSS inheritance wasn’t my problem.

As usually happens when you can’t figure out a problem, I had more than one.  So tweaking one of those settings wouldn’t show me any difference.  But, by carefully progressing from the working model to my version, I was finally able to ferret out the buggers.

First, Matthew’s approach sets the main fluid (center) section to a width of 100%.  But my theme set the width of an outer box to 96%.  That apparently allowed WebKit (and Opera’s Presto engine) to extend the logical edge of the inner section outside the outer box, squeezing out the sidebar.  I removed that outer 96% setting and changed the inner one to 96%, letting the inner divs push the outer one out.

Second, it appears that WebKit and Presto count border widths in addition to the width specified for a section.  Those widths had to be added to the size of the padding for the container and the negative margin used by the sidebar, to prevent two pixels of borders from squeezing out a 200+ pixel sidebar.

The net result moves the sidebar a little to the left from where it was in Firefox before, but I can live with that.  Let me know if you spot any other Knights Who Say Ni!

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

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!