← Home

Looking for the perfect Mephisto TagCloud plugin

Not so cute ...

If you've been looking for a tagcloud plugin for Mephisto lately you've probably been looking at the Mephisto Liquid Plugins wiki page and found these:

The former of these will hit your database once per tag that is listed in your tagcloud, like in:


{% for tag in site.tags %}
  {{ tag | size_tag }}
{% endfor %}	

... where in #site_tag the taggings for the particular tag are counted. I don't know about you, but to me that's not acceptable. But even worse, the latter of the plugins above will hit the database twice per tag!

Also: (I'm really not up to diss somebody particulary, but) this is just bad HTML:


<span style='font-size: 0.80em'><a title='annoyances' 
href='/tags/annoyances'>annoyances</a></span>

When I've been first looking for a plugin I haven't been able to find any reasonable solution ... so I came up with my own plugin that worked well enough for myself. You can see it at work in the sidebar of this blog and the code lives in my SVN repository for quite some time now: http://svn.artweb-design.de/stuff/mephisto/mephisto_tagging/.

What's on the wishlist?

In my opinion there are some requirements a nice tagcloud plugin will fulfill. Nothing new, really. But obviously worth mentioning:

  • Use one query to fetch the tags/taggings and counts from the database, not n+1.
  • Don't hardcode any kind of style-information into the ruby code. Leave it to the user to choose styles by defining a css class attribute.
  • Use reasonable semantic HTML. Ideally leave it to the user to decide if he wants an UL tag for the cloud with LIs for each tag or just a P tag with several A tags.
  • For different sites different distributions of tag counts to sizes are appropriate. So these should be configurable by the user.

Also: Some people want the tag counts to be displayed as plain text (e.g. in the link text), others don't want them at all or want them to be in the link title attribute. Some people want their tagcloud to use the hTag microformat. Others don't care. So ideally stuff like this would be either configurable or left to the user.

My own plugin does not fullfill all of these requirements, but most of them. I therefor hesitated to publish the plugin (hence there's been no notice about it on this blog, yet) before I haven't got around to refactoring it accordingly: I believe the best solution would be to rebuild it as a custom Liquid tag (as opposed to a Liquid filter).

Now, that task has been lingering around on my todo lists for quite a while. When I checked Google yesterday for some documentation or examples of how to implement the plugin as a Liquid tag I found an interesting alternative to the both pugins mentioned above!

The alternative

This plugin http://svn.boldr.net/mephisto/plugins/trunk/mephisto_tag_cloud has even been on the web ever since January 07. It aviods most of the mistakes mentioned above and even implements a custom Liquid tag! Wow, that's cool.

I installed it in my local copy of my blog and played around with it. Unfortunately it's not perfect, too :) From my perspective there are the few shortcomings.

  • The boldr tagcloud plugin distributes the tag counts equally to ten CSS classes. One could argue that this should sufficiently work in most cases because you can define, e.g., the classes .tag1, .tag2, ... to have the same properties if you want (and thereby define some custom destribution scheme). But of course, that's not really elegant.
  • As far as I can see it's not possible to access the tag count from within the Liquid tag. I.e. it's not possible to display it, neither in the link text nor in the link title attribute.
  • The README suggests to use Mephistos build-in link_to_tag filter which doesn't allow you to add any custom attrributes to the link though. Thus a tagcloud that consists of a pure list of anchor tags (as opposed to an UL cloud with LI tags) couldn't be implemented without further efforts. Of course one could add an additional Liquid filter easily for this purpose though.
  • Also, there are two minor bugs in the implementation which caused the plugin to display no tags at all for me initially. (See below for a patch.)

So, there's some room for improvement IMO.

I've briefly looked into it and I believe that things could probably refactored very easily. I'll try to either get some improvements into the boldr plugin so that it get's usable for myself or I'll just merge it with my own plugin and re-publish it myself. I've left a short note on the boldr forums and asked to contact me on this. (I used the forum because I found no other obvious way to contact the developer. If you happen to know one, please tell me!)

Your thoughts?

blog comments powered by Disqus