If you setup an "Article" content-type, and a "Review" content-type with Fivestar CCK fields targeting an Article node (ie, via a NodeReference CCK field), the fivestar ratings and targets are recorded properly in the content_type_review table, but nothing shows up in the votingapi_* tables.

For the ratings to register with VotingAPI properly, you MUST also enable "Fivestar ratings" on the *target* node's content-type (ie, the "Article" content-type in this example). A cursory inspection of fivestar.module leads me to believe this is by design; _fivestar_cast_vote() always calls _fivestar_validate_target() to test the target.

Regardless of whether this requirement is by design or not, it is not covered in Fivestar's documentation on how to use CCK fields. The documentation only specifies that the review's Node ID (ie, the "Voting target") must be populated for the vote to register with VotingAPI. (Ie, "no vote is registered in VotingAPI without the Node ID field filled out")

Additionally, the documentation gives the distinct impression that the "Simple Rating" configuration (in the content-type settings for the target node) and the CCK configuration (in the field settings for the "review" node) are wholly independent of each other; it reads: "Fivestar has two COMPLETELY SEPARATE modes of operation. The first is letting an end-user rate a piece of content. The settings for this are on the content type settings page."

And finally, in the step-by-step instructions for "Configuration as a CCK field / Advanced Rating", nowhere does it mention that you need to enable anything on the target node, it only discusses the review node, and mentions that CCK ratings "COULD be combined with a standard rating on the target node".

Well in my testing, this is inaccurate phrasing; CCK ratings *MUST* be combined with the "standard rating", at least insofar as the latter being enabled, even if it is unused or hidden from the end user.

I think this point is causing confusion for developers trying to use Fivestar in "pure CCK mode". I've seen a few comments scattered around that seem to indicate others have discovered this "hidden requirement" as well, eg:

http://drupal.org/node/243012 - Comment #25: "I realized that if the target node type does not have voting enabled, the vote will be disregarded entirely. [...] it would be ***extremely*** useful if a comment could be added to the 'target node id' config area that makes it crystal clear that the target node type must have fivestar enabled."

http://drupal.org/node/248503 - Comment #5: "if I enable fivestar on the parent node itself as well as for the cck field, I can vote on the node from the front end, then edit the original review (parent node) and the cck field fivestar rating will then register."

--

So to sum up... if "Review" nodes built using Fivestar CCK should NOT need the target node to have "Fivestar enabled" for ratings to register properly with VotingAPI, then this is a bug and should be fixed. If, however, this IS by design, then the documentation (and/or help text in the admin interfaces) needs improvement to clarify this very important point.

Currently, to get Fivestar working in "pure CCK mode", you should enable "Fivestar ratings" for the TARGET content-type, but set the Teaser and Full node displays to "Hidden" to hide the unwanted simple rating widget from end users. I also believe this is a much simpler answer to the "$50 Documentation Bounty" question (http://drupal.org/node/208054) than using some workaround with NodeComments as presented.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

quicksketch’s picture

Title: Fivestar CCK fields do not register with VotingAPI unless Fivestar is also enabled on the TARGET node. » Make Fivestar CCK fields indedepent of direct rating settings
Category: support » feature

I think you're right, the CCK implementation should be independent of the Direct rating widget. Especially considering that the configurations are far removed from each other, and the CCK field implements it's own voting mechanism almost entirely anyway (so does the comment-based rating, but it's pretty closely tied to the direct rating widget UI-wise, so there probably no need to change it there). So let's move this to a feature request and it'll be on the TODO list.

brian_c’s picture

I think the easiest way to accomplish this would be to add an extra parameter (with a default of false for backwards compatibility) to fivestar.module: _fivestar_cast_vote(), which would allow callers to force the vote to be accepted, regardless of target (ie setting this parameter to true would cause _fivestar_cast_vote() to bypass the _fivestar_validate_target() check).

Then fivestar_field.inc: fivestar_field() can use this parameter in its two calls to _fivestar_cast_vote().

Hope this helps, sorry I don't know how to submit a proper patch.

gunzip’s picture

FileSize
2.07 KB

i've struggled with this one hour then i've seen this. here is a patch to review against .13

gunzip’s picture

Status: Active » Needs review
quicksketch’s picture

Status: Needs review » Active

gunzip, your patch doesn't relate at all to the issue. Please open a new issue and describe what the problem is and what your patch fixes. It'll probably be affected by #318610: CCK Fivestar: deleting review node does not remove votes with axis other than 'vote'.

quicksketch’s picture

Status: Active » Needs review

Oh geez, I was looking at a different issue. I'll give this a review shortly.

quicksketch’s picture

Status: Needs review » Fixed
FileSize
2.41 KB

Thanks gunzip, I renamed the parameter $skip_validation instead of $force and removed new lines. Otherwise no changes. Committed. Thanks!

quicksketch’s picture

Erg, sorry there's a stray dvm() in that patch that's been removed. :P

gunzip’s picture

thank you. will the -dev release be available in the project page ?

quicksketch’s picture

You can always get the dev release by clicking "View all releases" then finding the 6.x-1.x-dev version. It's updated every night automatically.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.