This looks like a very useful WordPress plugin. It de-clutters the admin page by removing unused or rarely used menu options. It profiles per user so if there are multiple authors each can set up the admin panel as he or she prefers.

When I get home tonight, I’m going to give this one a spin!

Gravatars are “globally recognized avatars” and are becoming more common among blogs, just as avatars have been around for a while especially on phpbb and other forums or on livejournal type social blogs. They are 80×80 pixel images (a variety of formats are supported, including the usual web suspects) and are rated (so that weblog owners could choose to block more violent or sexual images from blogs used by children, for example). Each gravatar is based on a md5 hash of the owner’s email address. When that address is used in a comment, the gravatar can be retrieved and displayed with the comment.

So I went and made myself a very simple gravatar, using the general theme from this blog and tried it out. It’s been fun seeing where it will appear — and I certainly didn’t expect to have Technorati start showing it in my little Technorati script but there it is, at the bottom of my sidebar! Half the fun has been seeing where the little critter will pop up.

For more social bloggers, this seems like a nice way to put a face to a name and for others, it seems like a good way to further nudge a bit of name/logo recognition one’s way.

And yes, of course there’s more than one Wordpress plugin for gravatars. There’s one that seems to have been the gold standard but is not working now and has been updated (or branched if you prefer) with this version which has been recently overhauled and among other things which tries to be nice to the gravatar server by caching local copies. The gravatar site itself provides this extremely simple one which simply retrieves the image directly from its servers. (It works fine in WP 2.0.)

A related one is a gravatar signup plugin which encourages people to sign up for a gravatar on the spot, simplifying the process.

I use the wp-CaTT plugin for a simple Technorati hook. All it does is add Technorati links straight off the WordPress categories I choose for each article. I like it because it is simple, focused, and fast. I don’t have to do anything extra — always a bonus, I’m very lazy — to get it to work, and it doesn’t slow down my website either (generally, DreamHost does that just fine all by itself). Other plugins I looked at got all complicated with specialty tags where I’d have to remember not only the syntax, but to do it at all while scribbling my notes down. Or, they had so many (admittedly very impressive) bells and whistles that I simply wasn’t utilizing all of them which always seems a waste. Or worse of all, they slowed the site down.

However, in my mad theme-a-thon of yesterday and in my subsequent tweaking of each theme to standardize them a little bit and so on, I noticed this plugin really didn’t handle different theme’s varying separators. When I print out the categories for each post, I do so via a call like this:

<?php the_category('<br />') ?>

What this does is it prints out the list of category links (linked to my own WP’s database of categorized posts). The parameter tells it how to separate each category, in the above case with br’s, so in that example, all the categories will be on their separate lines (this is from the Barthelme theme). There are all kinds of possibilities: Chocolate Bar uses vertical bars as separators, and DR’s default theme uses commas.

The wp-CaTT plugin, however, is set up so that when I drop it in and use it, I need to edit its php file to set a variable to the same value used in the call to the_category.

Obviously when I started using multiple themes, that became a problem. So I went poking about in the plugin’s code, and found this:

    // 1. SET THE Delimiter TO THE CHARACTER YOU'RE USING TO SEPARATE MULTIPLE CATEGORIES APPLIED TO THE SAME POST.
    // FOR EXAMPLE, IF YOUR INDEX.PHP FILE CONTAINS the_category(', ') YOUR Delimiter IS ", ".
$Delimiter=", ";

which I replaced with (after tinkering with several other ideas):

    if (preg_match("/,/", $url))
            $Delimiter = ", ";
    else if (preg_match("/<br ?\/>/", $url))
            $Delimiter = "<br />";
    else if (preg_match("/ \| /", $url))
            $Delimiter = " | ";
    else
            $Delimiter = ", ";

There’s probably a better way to gracefully handle it if none of the matches work. I thought of defaulting to a simple space, but the problem is the $url variable is basically a list of href’s so there’s plenty of spaces, and such a default if it got used would result in a mess on my screen. I suppose that would be one way to alert me to the need to add another check.

I’ve been trying to think of a nice way to allow wp-CaTT to be flexible about what it can recognize and match against. One issue is that the $Delimiter variable needs to be set to whatever the actual delimiter is. I can’t just use a longer regexp that combines all the terms, because the plugin reassembles the original href’s with the added Technorati tags, using the delimiter. In addition, I can’t just use the list of delimiters straight, I have to regexp-ify them. In other words, the delimiter " | " has to be escaped because the vertical bar carries special meaning in regexp’s. Or the br took an optional space (” ?”) because some people put down <br /> and others <br>. Hmmm…I suppose people also put down just <br>, too… ‘k…

   else if (preg_match("/<br ?\/?>/", $url))

that fixes that…

I suppose I could take the tack that the Technorati bubbles themselves become the separators, and leave the delimiter empty. But then a theme like Barthelme points out the need to preserve it anyway, because Barthelme prints each category out on its own line and the cleanness of that presentation is spoiled if the categories start wrapping instead.

Why, lookit that:
XML::Parser::Lite::Tree::XPath
It works!
So I let the author know about the mods, if he wants them. But in looking at the code to do this, I think I’d be happier with a “Lite” version. Don’t get me wrong, this is a lovely plugin if you want all of its features. I simply don’t: not the MSN smilies, and not the java stuff. I had to disable it to keep it from slowing my system down. Plus, in the course of modifying the code, I discovered it makes three passes over the content of the entry. Why? I think again cos of the javascripts, but now I want to look at this and see if I can make it a bit leaner and meaner…

And, no, I don’t mean the trendy kind of mashup that’s all the rage in 2.0. I’m talking about when plugins collide. Particularly plugins that run through the_content of a WP blog entry. I have two such at the moment: one that inserts smilies into the text such as this and I have another that renders code within <code> elements as completely unprocessed elements. The two together give rather unfortunate results for:

<code>XML:: Parser::Lite::Tree:: XPath</code>

(notice the strategically placed spaces before Parser and XPath…) as something like:

XML:<img src=’http://www.digitalramble.com/wordpress/smilies/yahoo_tongue.gif’ alt=’&#58;&#80;’ class=’wp-smiley’ width=’18′ height=’18′ title=’&#58;&#80;’ />arser::Lite::Tree:<img src=’http://www.digitalramble.com/wordpress/smilies/yahoo_love.gif’ alt=’&#58;&#88;’ class=’wp-smiley’ width=’18′ height=’18′ title=’&#58;&#88;’ />Path

Ahem.

Now clearly, it isn’t always possible to avoid plugin collisions. Some are just inherently incompatible with one another. But I have to wonder about the notion of indiscriminately putting smilies in where one might not want them to appear, such as in code elements.

There are probably some alternatives. For example, I could use Simple Code to generate unrendered code samples that view properly. But the same reason that this plugin would not collide with the Smilies one is the reason I don’t care to use it: it provides an option under the Write admin panel to cut and paste the code in, and the protected result out. This means that when I’m writing up a post, I have to save it, go to the SimpleCode option, paste the code i want, copy the results, then go back to editing. If I navigate away and neglect to save, I’ll lose what I was writing. Given that I tend to go back and forth with snippets of code, and given that this is a technical blog with lots of code, that’s not convenient (although, I must say it came in handy for massaging the above example, which will go away otherwise when I fix this collision). However if the output from SimpleCode contains anything the Smilies might match, I’m still stuck with potential Smilies appearing even in this.

I could drop the Smilies plugin but just as I’m geeky enough to want the code feature, I’m geeky enough to want the Smilies in the right place.

Hmmm…I foresee some modifications to this plugin.