In a previous post, I’d mentioned that I’d installed the hReview plugin, but then deactiviated it due to “problems”. A comment from the author of the plugin, Andrew Scott, asked what those problems might be, and I realised that I simply hadn’t given the plugin a fair go before dismissing it. Below is my review of hReview (marked up as a microformat *using* hReview, naturally), though my styling could do with a tweak.
Newer versions of this plugin have been released since the review was written that may have fixed the negative bits mentioned below.
product
hReview WordPress Plugin does the job well
The plugin installs fine, and activates without a problem. It appears on the Write Post page as either a star or the word “hReview” (depending on if you use the visual editor or not). Selecting the star/hReview brings up a dialogue box where details of the review can be entered in. Comparing it to the hReview specs, I can see that it does cover most of the items, although some of the optional bits are missed out.
When I first used it, I’d tried using the
type
option to specify a product. In the visual editor this just came up as a single word in a paragraph of it’s own. Now a word is not a paragraph, so perhaps this should be marked up as a span instead. Looking at the code view, I can now see that some inline styles had been applied so that the paragraph was set todisplay: none;
anyway. Now I know I can hack the plugin, or my own CSS, but I would prefer this word to be in a span, capitalised, with a colon, before the item name – so in this review it would have said: Product: hReview WordPress Plugin. Othertype
s would have the same effect. Simply having (optional) data included in the source for the sake of a microformat, yet not displaying it visually is kind of against the microformat principles.Using the dialogue box, once the content of the review has been inserted into the post editor, adding more content means looking in the code view and working out which bit you want to edit. This is fine if you have any idea about HTML, but may be scary if you don’t. Clicking the star/hReview button again brings up a blank new review box, rather than being able to edit the first review. Perhaps clicking the star should bring up the existing review, but have a button on the dialogue box for a new review (a form reset button in effect).
Lastly, part of the spec mentions the use of
dtreviewed
,reviewer
andlicense
. These are optional data that can be included with an hReview. Sadly, the current plugin doesn’t cater for these, which, although they are optional, may be important to certain reviewers. Ideally, thedtreviewed
could be added to the post date (the specs do suggest this), and thereviewer
could be added to the author data, marked up as a hCard (the specs say parsers should look outside the hReview if areviewer
can’t be found inside the review). Of course this would mean adding it into the WordPress templates, which may or may not be possible via scripting the DOM. Alternatively, settings on the dialogue box would be better and solve the problems above, as the reviewer may not be the poster, and the review date may not be the posting date. A drop down list of common licenses should also be available – those who know what they are can use it, or it can be optionally left blank.Overall, the plugin does the job it claims to, and I admit that my previous comments were unfair (I’ll go highlight it in that post shortly).
It would be nice if the Operator / Tails Firefox addons offered support for hReview, and perhaps the author of hReview may wish to contribute to those as well.The Operator addon does offer hReview support, although this hReview wasn’t detected due to what I believe is a small bug in the plugin – see the comments. If you intend to carry out reviews of any sort, and use WordPress, then the hReview WordPress Plugin from Andrew Scott is for you.
Comments
2 responses to “Review: hReview WordPress Plugin”
Thanks Gary for the detailed review. It’s clear you have a very good understanding of microformats.
I did ponder what to do about the review type field. Personally, I find it a bit annoying, and I’ve considered removing it from the plugin. However, I think I followed the approach used by the hReview Creator page (http://microformats.org/code/hreview/creator) which used the style attribute to prevent it displaying. However, since it’s invisible, I could position it before the summary so that people like yourself could change the CSS and have it display as they wish.
The other optional things I generally left out to keep the user interface and code simpler. For example, on my own site, I have an hCard on every page anyway, and so I didn’t need to add support for another hCard within each review. I suspect most blogs will also take this approach, unless they have multiple authors contributing to the blog.
FYI, the Tails Export plugin for Firefox https://addons.mozilla.org/en-US/firefox/addon/tails-export/ supports hReview.
Hi Andrew,
I believe your hReview Plugin does have a small bug. In all the examples I can find (see below), the fn of the reviewed item should be inside the item level (a bit like fn should be inside a vcard, not at the same level):
So:
Something
is fine, whereas:
is not. Combining this with the url data is most useful, giving:Something
hReview WordPress Plugin
Without this tweak, the Operator plugin does not successfully detect the plugin (except in debug mode).
The examples where fn is inside item:
http://microformats.org/wiki/hreview#Restaurant_reviews
http://www.golfdigest.com/golf-courses/golf-course-finder/abacoa-golf-club-jupiter-fl-2483
http://www.novedge.com/review/1978/
Actually, the http://microformats.org/wiki/hreview-profile sums it up nicely.
fn
is a sub-property ofitem
.