RSS-based comment moderation?

I just left the following ticket on WordPress Trac, as a feature request:

RSS feeds are already generated for posts and comments by default. What would be very helpful woudl be a dedicated RSS feed for comments in the moderation queue. This would permit efficient queue processing without having to log into the Dashboard.

For added functionality, each item in the RSS feed could have unique URL hash address links for approve, reject, and spam, so that moderating directly from the RSS feed could be possible from within the feedreading application. the RSS feed would need to be password protected or made visible to any user level that the admin desires to set.

(Trac Ticket #7452)

plugin wanted: Author Tags

Had another idea for a useful plugin – what is needed is a plugin that creates a tag cloud/tag list on a per author basis. This would be especially useful for group blogging sites (like Talk Islam). The plugin would ideally allow a simple function call with arguments:

– user name (login)
– number of tags (defaults to 5)
– list or cloud format (defaults to list)
– list delimiter (defaults to ” | “)

On a bio page or About page, this would be very cool because it would let you see at a glance what topics each author blogs about most.


I was out of town this weekend, to celebrate my daughter’s first birthday in Chicago with my parents, so I figured that I’d throw a fun post up on the blog for you all to enjoy. Unfortunately, Akismet seems to have decided to stage a coup in my absence and tried to eat everyone’s comments, which seriously blunted what would have been a really fun thread. I just returned home and found Akismet drooling like Smaug over its hoarded commentary, loath to release them until I forced it to my will. Maybe it’s time to look at serious spamtrap alternatives.

In the meantime, how about that wacky telescope thingy, eh? (sigh). I know. Thread’s dead, baby.

beyond the tag cloud: the tagdex

I think tag clouds are somewhat useless, to be honest. They are a nice way to fill up a bit of space in a sidebar, if you restrict the cloud to the top 25 or so, but unless the writer is imposing a strict taxonomy on themselves, ultimately the size of the cloud will balloon to an unmanageable size. And a tag cloud in a folksonomy makes no sense, because the wide variation in tags is a feature, not a bug. You want the tags to be vast and redundant. It is ok to have a post about Jhumpa Lahiri’s latest novel tagged “book”, “books”, “review”, “Lahiri”, etc. because this increases the points of entry to the content from tag indexing services like technorati, and also increases the intra-blog, inter-post linkages (assuming you are using some variant of a Related Posts plugin that uses tags for determining what is related).

A far better way to think of tags is to consider them as terms in an index. The same kind of index you find at the end of a piece of non-fiction, to be specific. Consider an excerpt from the Index to the book, The Physics of Star Trek, as an example:

excerpt from second page of index to Physics of Star Trek

It’s easy to see how tags could be recruited to “build” an index of this type. The tags would first need to be sorted in alphabetical order, and then listed as a DL-type HTML list with the “page number” (post number). A range of posts coudl be indicated by the usual dash (ex. Bosons, 192-194) and a list of separate posts by commas (Black Star, 15, 51).

That would be the crudest implementation, but quite effective. However you could go further than this. For example, what about the “see also” link? You could simulate this by looking for tags whose usage is highly correlated, like “Lahiri” and “books”. You could literally calculate Pearson’s correlation coefficient between all pairs of tags in the database and store that in a lookup table, which woudl be updated whenever a post is published. Then any tag whose correlation coefficient to the present post is above some threshold (say, > 0.50) would get the “See also” treatment on both tags’ entries.

You coudl even draft categories in wordpress to contribute, by using them as “tags” in their own right and lumping them into the regular index build (after all, as implemented in WordPress, tags and categories are just redundant taxonomic systems). However, you also might look for correlations between tags and categories, and use the categories as Index parent terms. An example from my own geekblog would be something like

Makoto Shinkai
Someday’s Dreamers
Geek Service

I had to manually generate the above but it would be far simpler to do it via correlation analysis instead. At any rate, the basic idea is to assign categories as index headings and tags as their cdependents, since presumably categories are more formally taxonomic, and more importantly, fewer. In fact you could do both, treating categories as tags and also giving them higher status as above. You would just need to put a logical test in to exclude a category from appearing as its own parent/child!

Obviously a tag-driven index as above wouldn’t fit in a sidebar. A useful place for it would be its own page, but you might also imagine it embedded on the 404 page. As a standalone, though, it would be a very useful node for search engine optimization, enough so that perhaps it should be called a “tagdex” instead of an index to better distinguish it.

Though useful to any blogger using tags on wordpress, a tagdex would be far more effective on a site whose tags were a genuine folksonomy rather than a taxonomy, since the tag diversity would be greater. However, folksonomy is not a feature of WordPress, unless you use Scott’s awesome WP-Folksonomy plugin (which he wrote in response to my earlier rant about taxonomies and folksonomies). If a thriving ecosystem of wordpress-based folksonomies can be encouraged to thrive (using Scott’s plugin, or equivalent), that will be a significant step towards the Semantic Web. A tagdex represents a coherent snapshot of all the tag metadata in that site’s folksonomy (or taxonomy). As such, it is something that could be parsed and aggregated by the hypothetical Semantic Search Engine of the future.

wavatars updated

Shamus announces an update to his wavatars plugin. However, as noted earlier, the pending release of WordPress 2.5 will likely break most avatar plugins due to its built-in avatar support. It think it makes more sense to wait for the post-upgrade version of wavatars for the time being; I still would like to see a way to define avatar libraries so that instead of two plugins, I could just select from a drop down of avatar styles (wavatars, monsters, etc).

close the barn doors

I thought I was done with this, but it seems that WordPress v2.3.3 did not fix the injection spam loophole; I was just hit by another injection spam attack on my previous post (now cleaned up). I’ve closed user registration on the blog for now, though of course you needn’t register to comment thanks to the captcha plugins I have installed. I suggest that all WP bloggers do the same and keep an eye out for injection spam by monitoring your RSS feed.