Rate on multiple axis with admin UI

Thanks for opening this issue DaniOrama.

I've been giving this some thought, and I feel like the adequate amount of configuration would be to set all the Fivestar options like you do currently, then setup the axes (apparently the official plural form of "axis"), in a new fieldset that contains axis and title fields.

So on the node type form the Fivestar fieldset would look like this:

[x] Enable Fivestar rating

Number of stars:
[ 5 | v ]

--Title and axis--
Number of axes:
[ 3 | v ]

Axis:            Title:
[ quality | v ]  [ Quality          ]
[ value   | v ]  [ Value            ]
[ vote    | v ]  [ Overall          ]

--Star labels--
(same as current labels fieldset)

--Direct rating widget--
(same as current direct fieldset)

--Comment rating widget--
(same as current comment fieldset)

To actually setup the available axes, create a setting under admin/settings/fivestar that is simply a textarea for entering the valid axes:

Valid axes:
|------------------------------|
|vote                          |
|quality                       |
|value                         |
|------------------------------|

Of course help text would be sprinkled around explaining all these settings.

Basically this would allow the administrator to setup any number of axes, as long as every axis had the exact same settings except for the title of each set of stars.

This approach would definitely allow different axes per content type. You'd have to visit admin/settings/fivestar to setup all the axes you need to use on your entire site, then visit each content type and turn on each axis you want to apply to that content type. So you could setup 10 total axes if you wanted, but then only have 5 enabled on one type of content and a different 5 on a different type (or any combination of axes/types).

The reason why we'd want the setup of site-wide axes separate from the node-type form is mostly for ease of implementation, but here's a list of advantages:
- The maximum number of axis is already known when configuring node types (because they're predefined at admin/settings/fivestar). Making the JS easier to implement.
- Predefining the available axes keeps the site consistently using the exact same axis names.
- The predefined axes can also be used in the configuration of CCK Fivestar fields.
- By using separate form elements on the node type form, the live preview can be updated after any change (versus a textarea could only update the preview on the "blur" event).

Marked #334138: Configurable voting axes a duplicate.

From that issue:

Proposed implementation:

1. Redesign fivestar configuration pages.
   • "List" default menu item lists available voting axes. "Vote" id installed by default and locked. There's an "Add voting axis" tab and an "edit" link next to existing ones.
   • Clicking Add voting axis brings up a form to enter a machine-readable name, human-readable name, plus all the existing configuration options for fivestar.
2. Rework the node type editing UI to select one or more of the existing voting axes (rather than just using "vote" as currently).
3. Make the CCK field voting axis configuration a select fro existing voting axes rather than the current textfield.

quicksketch and I discussed this issue. We're moving the system to administer voting tags/axes to an issue on Voting API, #335668: Add system for registering voting tags (axes), which I will take, and quicksketch will take this issue.

I posted a patch to #335668: Add system for registering voting tags (axes).

Since it seems that the votingapi-patch thread has not come to an end yet, what does this patch actually do? will my old tags still work? would the rating_widget settings change?

I mean, I have a problem here with average rating on different axes, which I am building with views. The problem is, that I get only the machine-name of the tags .. Furthermore (due to the sql table layout of voting api), the results are not sorted, though I can work around this by creating a view-template for it that corrects the order statically ..

Nonetheless, I'd like to have the same output for the tags as for the field labels. Right now, I've to do that on my own somewhere, right?

The attached patch (against 6.x-1.13) allows Fivestar to be configured with multiple vote "tags" (axes) when voting on nodes.

Under admin/settings/fivestar, you can specify the available tags as a comma-separated list.

Under admin/content/types -> edit, there is a new tab "fivestar voting", replacing the old fieldset on the edit page. Within this are subtabs for each defined tag. You can enable/disable each tag individually on each content type, and you can customise all of these variables per content type per tag.

I've attached some screenshots showing it in action.

The variables that were previously fivestar_VARNAME_CONTENTTYPE are now fivestar_VARNAME_CONTENTTYPE_TAG with one exception: if the tag is "vote", the "_vote" at the end is omitted to maintain backwards compatibility.

All code that reads the below variables now utilises the new function fivestar_var_suffix($type_name, $tag) to get the variable suffix.

fivestar_[type]_[tag] - enabled (bool)
fivestar_stars_[type]_[tag] - number of stars (int)
fivestar_labels_enable_[type]_[tag] - display labels on mouseover (bool)
fivestar_labels_[type]_[tag] - labels (array)
fivestar_style_[type]_[tag] - star display style (average/user/smart/dual)
fivestar_text_[type]_[tag] - text display style (none/average/user/smart/dual)
fivestar_title_[type]_[tag] - show widget title (bool)
fivestar_feedback_[type]_[tag] - enable feedback during vote save/deletion (bool)
fivestar_unvote_[type]_[tag] - allow undo vote (bool)
fivestar_position_teaser_[type]_[tag] - teaser display (above/below/above_static/below_static/link/hidden)
fivestar_position_[type]_[tag] - full node display (above/below/above_Static/below_static/hidden)

Javascript and non-javascript form generation and voting have both been tested.

Note that I have attempted to improve the readability of the patch by not indenting unchanged lines (even when they moved inside a block). So you may wish to reformat this patch before committing.

This change should not be incompatible with #335668: Add system for registering voting tags (axes) and I propose that this it is released immediately. When 335668 is in place, it will only be necessary to remove the textfield and reimplement the fivestar_get_tags() function.

Improvements that could be made:

1. Add a custom "title" per node-type/tag. At the moment I'm just suffixing " (Tagname)" to the titles when the tag isn't "vote".

2. I have not changed the views code since I don't use Views. However it should continue to work; just only with the default "vote" tag. Someone else is welcome to upgrade this to work with multiple tags.

3. When a tag is deleted through the main admin page, it would be possible to delete all of its variables.

4. It's not possible to add "fivestar" to the "Operations" column in the content-types table due to a TODO in CCK (content.admin.inc line 32). When this is fixed, a link can be added there.

5. The comma-separated list in the main admin page could be a more elaborate UI if you like, though it seems unnecessary if this functionality will eventually be moved to votingapi anyway.

N.B. Other changes included in this patch:

1. fivestar_node_type() - I added more variables since it was missing a few.

2. fivestar_node_type() - 'update' didn't work ($type was never set) so this is now fixed.

3. fivestar_form() - I renamed this to fivestar_voteform because, as someone noted in the comment, it's not a hook_form implementation.

debug line should be removed:

drupal_set_message("Set $key$var_suffix to $value");

Live example in action: http://goofans.com/download/level/jingle-balls

I'll post a cleaner patch later; there are a few debugs/comments to remove, and hook_nodeapi is grouping all the stars together even if they're configured with different positions.

Thanks davidc for this amazing patch! The whole multi-axis rating has been held up in VotingAPI, where they're working on a central place for entering available axis: #335668: Add system for registering voting tags (axes). This would then change your implementation slightly so that we would pull from VotingAPI rather than Fivestar's settings.

Regardless this looks like quite the update. :-)

I like that you've split Fivestar out into a separate tab, in actuality we were probably taking up too much space on the content type form anyway. I'm swamped right now trying to get out stable versions of FileField and ImageField, but please continue with this awesome work and I'll review it when I get the chance!

Hi quicksketch,

I was aware of #335668: Add system for registering voting tags (axes). This work isn't incompatible: when votingapi_tags is released, fivestar_get_tags() can simply be replaced with votingapi_get_tags(). This is one reason for the current simplistic admin UI for defining tags in fivestar, and why there are two ucfirst($tag) calls at the moment rather than having another UI for the site admin to define the title (since the title will be eventually part of votingapi_tags).

I'm shortly going to be testing out Views, so I'll try and add better fivestar/views/multitag support. I'll also clean up the patch a little and post it later this week. Then it'll just be up to you guys to convert it to use votingapi_tags whenever that's ready. Like I say it should just be a matter of changing the _get_tags() and ucfirst($tag) lines. I'll mark them in the code with TODOs.

-davidc

Great patch.

Is there anyway to get one of the widgets to display an overall rating, not necessarily through the admin UI, but through some PHP code?

sorry i'm starting with fivestar and i'm a little bit confused.
is there any difference between this approach vs creating a cck fivestar field for each axis then specify it in the "Voting Axis" field setting ?

@Quicksketch;

Thank you for pointing me in this direction. This is working perfectly on my test site. I'm in the middle of copying a database snapshot of the main site into my test site so we can do some more in-depth testing of some of these new modules before upgrading the production site to Drupal 6 - so I will let you know if something new pops up. But so far this is great and I'm having no issues.

I've just patched the fivestar module (6.x-1.13) with davidc fivestar_tags.patch 27.54 KB (above) and I am getting a division by zero on the edit content type page.

    * warning: Division by zero in \fivestar\fivestar.module on line 1600.
    * warning: Division by zero in \fivestar\fivestar.module on line 1601.

its happening when its trying to render the fivestar preview in the fivestar comment settings (see png attached).

This leads me to a question, is it the intention to be able to apply multiple fivestars to the fivestar comment. The help text on the fivestar voting tab implies this ... 'These settings will be used for both comments (if available) and direct rating', I don't really know the codebase but since fivestar_comment.module has not been patched I am assuming this is not in place yet, so I was wondering what (if any) plans there are for this - or have I missed a patch or something more fundamental?

Try the latest dev version.

Alright, I reviewed this and made several changes to get this updated to work with the CVS version.

Changes made:

• Updated code style to match standards: http://drupal.org/coding-standards (removed tabs and properly indented)
• Reduced changes to function names which would likely break existing sites upon upgrades. Let's keep function signature changes to a minimum.

Things that need to be fixed:

• Fivestar Comment needs to be updated to work with this also.
• Tested like crazy.
• Once finished, we need to backport to Drupal 5.

Thank you very much for the effort to finally make multi-axis voting a reality.

It still seems to need some work, though.

I downloaded the -dev version of fivestar (dated April 11) and applied the patch, which caused some complaints:

$ patch -p0 < fivestar_tags_0.patch
patching file fivestar.module
Hunk #16 FAILED at 814.
Hunk #24 succeeded at 1116 with fuzz 1.
1 out of 32 hunks FAILED -- saving rejects to file fivestar.module.rej
patching file fivestar_comment.module

I'm adding the fivestar.module.rej file as an attachment (with .txt added as an extension, so that Drupal doesn't complain).

Also, when a node with various voting axis is accessed by a user with permissions to vote, the whole thing crumbles down with a fatal error:
Fatal error: Call to undefined function dsm() in /home/borfast/projects/www/writersfederation/sites/all/modules/fivestar/fivestar.module on line 1096

Turns out dsm() is a function from the devel module, so perhaps it should at least be wrapped in a call to if(module_exists('devel')).

Pretty new to this but I thought I'd give some help.

As quicksketch mentions the last patch fivestar_tags.patch needs further work especially on the fivestar_comment side, I've applied quicksketches patch to the latest dev version and sorted out a few of the issues (removing the dsm call in fivestar module that was causing error). I've also updated the fivestar_comment.module to work with tags, this has required a schema change to fivestar_comment table.

This patch attached will update fivestar.module, fivestar_comment.module and fivestar_comment.install. I've put significant comments in the db update to explain why it is a bit more long winded than it should be. I would appreciate quicksketch reviewing this and incorporating the changes if he thinks they are appropriate. I've never created a patch for drupal but I followed the guidelines so hope everything is ok.

Sorry patch without CR endings ....

Sorry, this is the correct patch, I got there in the end, this is against fivestar-DRUPAL-6--1 from cvs.

I noticed an issue in the previous patch I posted whereby the star labels were not displayed as entered through the admin UI, I have fixed this and attached a new patch. Just a note this patch incorporates all the changes so you should be able to just install this and get fivestar tags across direct rating and comments. Again this is against fivestar-DRUPAL-6--1 from cvs, so make sure you are patching this and don't forget to do a db update to get the new column for fivestar_comments.

Hope this helps everyone to get this functionality into fivestar.

sped2773, could you please remove the absolute file paths from the patch? Just leave the file name instead of the full path.
It won't work otherwise and the issue system won't accept it if it has errors.

Thanks!

Can this setup be used to make the presented icons appear different for different axes (i.e., can i get it to have one axis of cheeseburgers, one of cats, one of stars, etc.)? Messing around - it seems to only want to make all the axes be the main type -- set in the Fivestar admin screen.

Is there some kind of custom call to make different Fivestar fields display with different icons? (i would also like to give the node's authors the ability to pick only one of the axes to be available/enabled for other people to vote on-"pick your own vote axis" option.)
(sorry if this is OT - seems to be the spot for hashing this out) -thanks & great stuff :)
EDIT: I found a tutorial on making different axes look different @ http://codebaboon.com/tutorial-different-icons-fivestar-cck-fields - thanx

Can this setup be used to make the presented icons appear different for different axes

Setting up different icon sets would require fundamentally changing the way Fivestar adds CSS to the page, so I think it'd be best discussed elsewhere.

A note from Likeless in #326436: Wrong messages and numbers when the number of stars is not set to 5:

For a future Fivestar version, are you still planning on fivestar_get_settings()? (ref. posts 16,18,26 of #280735: Add fiveestar vote on comment without nodecomments module).

This patch currently makes a separate function for fivestar_var_suffix(), which is a good idea in that it reduces redundant code, but I'd like to see it converted to a function that gets the entire setting, rather than the suffix. Something like: fivestar_get_setting('setting_name', $node_type, $tag);. This way we'd be able to consolidate all of our default values for settings in a single place, and make the code clearer to read.

I'm also considering making this patch the branch-point for Fivestar 2.x, as I think it's a reasonable enhancement to warrant a new version, and I think it's time to drop support for Drupal 5 so that Fivestar can develop faster without worrying about compatibility problems in Drupal 5.

I'm running 6.x-1.15 with sped773's patch (#25) and all seems well.

Is this a good point to commit it to CVS so we can do cleaner diffs, e.g. I'm happy to work on #30, and I also want to add customisable per-tag-type titles. Or should I just do a consolidated patch, or a patch against the other patch?

I've committed everything so far to a new 2.x version. There are several things wrong with the implementation, but we can work these all out in separate issues. Anyone working on this code should switch to using the HEAD version out of CVS, which I've updated and restructured.

Huzzah for version 2. :-)

Followup issues:
#459682: Display Settings for Multiple Axis
#203162: Add an admin option to overwrite the title of the FiveStar widget

Except for the May 11 2009 version found at http://drupal.org/node/459660 these multi axes rating can't be found anywhere. Not even on CVS HEAD which apparently has version 1.19.

What is the status of the evolution of version 2.x? Where are people discussing this evolution? Where code is evolving ?

Thanks in advance.

subscribing

subscribing

I found the 6.x-2.x-dev version here: http://drupal.org/node/459660

@docmiller, yes, thats the only place thtat the 2.x-dev is consistently accessible. And there is still a lot of work to do

I'd like to urge the mainteiners to put this new version in the project page to drive more attention and eventual contributions. The way it was released I believe it will never evolve.

Subscribing, greetings, Martijn

Did this issue die? What ever became of allowing setting up axes on the node itself?

Oh whoops, don't I feel silly! It's in -dev.