Closed (fixed)
Project:
Fivestar
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
30 Apr 2010 at 12:36 UTC
Updated:
3 Mar 2011 at 08:27 UTC
Jump to comment: Most recent file
Comments
Comment #1
ctrnz commentedAs I've found out - it does not happen when static display is chosen.
However - when You choose static, then static it is for ALL tags. But that is different issue i suppose.
Comment #2
ctrnz commentedBuggy functions fivestar_form $settings array caused this.
Here is what I finnaly get
Removed 'tag' which was twice in array and added in each variable_get call missing "_" before $suffix.
Comment #3
abaddon commentedheres a more elaborate patch that takes into account your fixes as well
the other fixes are in fivestar_nodeapi(), if you dont enable the default "vote"-tag, the other ones will not be enabled as well, also position is taken from the default one, ive fixed these 2 issues, so you can just display your own custom tags without the default one, and positions are independent of each other (one can be static, one above, one below, it doesnt take these from the default "vote" one anymore)
Comment #4
Fidelix commentedabaddon, your code is good.
But the patch does not work, i get the following output:
patching file fivestar.module
patch unexpectedly ends in middle of line
however, manually making changes in the code solves the problem.
This should be commited ASAP in the dev version, for it is simply not working ATM.
I thank you for the effort!
Regards.
Comment #5
dgastudio commented+1
Comment #6
jghyde commentedThis patch was rolled against DRUPAL-6--2 today. It is the fixes mentioned in #2. I haven't had time to roll through #3.
This patch fixes the primary problem, that of the fivestar widget not accepting the saved settings like for displaying 10 stars instead of just 5.
Comment #7
jghyde commentedThis one takes into account both instances. I am seeing trouble with the average vote sent to the theme function. I am not sure it's getting populated (the average vote) in the array.
Anyway, this code appears to solve a majority of the problems. Please test this patch and modify as necessary. patched against DRUPAL6--2-- on CVS. (Head is D7).
Joe
Comment #8
jghyde commentedThe above patches broke the display of the vote totals on the fivestar widget. So this is maintenance on the above, and I think makes this patch ready for primetime. Please test.
This patch fixes the confusion between the votingapi's type of object (or array) returned as the cached votes results. Looks like we've fluctuated between object $results and array $results. Now the vote totals will appear on the fivestar widget as advertised. It was an array() of values, not an object.
This patch rolled against fivestar-DRUPAL-6--2.
Tested against votingapi version 6.x-2.x-dev:
Comment #9
willvincent commentedPatch in #8 works well.
Thank you!
Comment #10
ezra-g commentedI think we've got code unrelated to the issue in the #7. This issue is about widget settings. If there are bugs related to the way the VotingAPI formats data, let's address those in another issue. I believe this patch contains the relevant fixes for the scope of this issue.
Comment #11
ezra-g commentedIt gets even better. With some debugging code added I saw that with the "Enable Fivestar rating for the [tag] tag" checkbox unchecked, the submit hanlder for the Fivestar settings form was never called. Craziness.
I tracked down to the theme function theme_fivestar_node_type_tag_form() -- Preventing this from running by commenting out its definition in fivestar_theme() resolved the issue. Mysterious.
Further troubleshooting showed that turning off javascript in the browser allowed the form submit handler to run regardless of the checkbox state.
Break out the Firebug net tool and it turns out in fivestar-admin.js,
$options = $('#fivestar-node-type-tag-form input:not(#edit-fivestar, #edit-submit), #fivestar-node-type-tag-form select');has the effect of unsetting *all* of the form elements, including hidden Form API elements such as the form id that we're submitting, resulting in a virtually empty POST when submitting the form, and thus the reason submit handlers never ran.Here's a revised patch that fixes the above by adding a containing div and doing a jQuery show() and hide(), rather than setting elements to disabled. This also changes the name of the 'fivestar' setting to 'fivestar_enable' which is somewhat more descriptive.
Comment #12
coltrane@ezra-g won't you need an update hook for changing variables?
Comment #13
ezra-g commentedYes indeed.
Comment #14
ezra-g commentedHere's a re-roll without the variable name change, which would also have to be taken into account in at least one other place. Let's keep the convention.
Comment #15
ezra-g commentedMissed an underscore, which made the above not actually work ;). I've tested a bit this time.
Comment #16
ezra-g commentedI marked #494150: Fivestar voting widget is only displayed if vote tag is enabled as a duplicate since they're both part of the same symptom "widget ignores settings" and we want to fix the symptom, rather than individual causes separately, which is more difficult over 2 patches.
This still needs an update function for old variables to include the 'tag' name, since this is seems like a better way of providing an upgrade path rather than always looking for outdated variable names.
Marking as NR so folks can verify the overall approach. I've tested with 2 tags and a few different display settings.
Comment #17
ezra-g commentedWith dpm removed :\.
Comment #18
ezra-g commentedThe widget settings are also not respected in the Views integration. I am working on a patch locally.
Comment #19
ezra-g commentedThe overall problem here is that FIvestar 2.x introduced the ability to vote on multiple VotingAPI tags per content type, but the module doesn't take this into account pretty much wherever it loads the settings for the Fivestar widget. So while previously you had one set of settings per node type and one for comments, you now have one set of widget settings per content type *per tag*. This still needs an update function to change old variable names, but at least gets the Views voting widget working in my testing.
And, there's quite a bit of testing required, since you can set the display location of the full node view and teaser (among other settings) for each content type for each tag -- That's a lot of permutations!
Comment #20
ezra-g commentedIn some places we were checking the widget setting value 'style' and in others 'star_display' for the same setting, causing previous vote values to not be loaded into the widget. This patch fixes that. Yay.
Comment #21
ezra-g commentedMarked #463840: Feedback and Glitches on 2.x-dev as a duplicate.
Comment #22
ezra-g commentedHere's a revision that fixes a potential foreach error in some views.
Comment #23
ezra-g commentedGuess who found more broken Views integration :) ? This time in the static widget.
Comment #24
ezra-g commentedSlight revision.
Comment #25
ezra-g commentedI found one more case of Views integration not respecting tag settings and fixed it.
Given that there was never a stable release of this branch and that it's difficult to work on other patches when the module at the core doesn't respect its own settings, I've moved old variable cleanup to #1052524: Clean out old variables in an update function and committed. http://drupal.org/cvs?commit=495324
I credited jghyde and googletorp for their work in this and other issues relating to this underlying problem of the 2.x branch having been started but not really finished. I think there was some overlap in identifying problems as a result of not seeing all the comments in all the issues related to this one. In some places we came to somewhat different solutions, in some places they were more similar.
Back in 2009, quicksketch said,
Here's to a 6.x-2.x branch that's, dare I say, not totally broken!
Hopefully this is helpful for the 7.x-2.x port that ericduran is leading.
Comment #26
ezra-g commentedFor example, the fivestar-admin.js javascript preventing the settings form from submitting. Folks identified and proposed solutions to this in at least three different places:
Myself in the present issue: http://drupal.org/node/786224#comment-4043906
#786244: Always enabled tag
#463840: Feedback and Glitches on 2.x-dev
However, it wasn't necessarily clear from issue titles and contents how these issues were relevant to the problem, at least without closer reading through potentially a lot of issues.
Comment #28
abaddon commentedjust an initial comment to the last updates, ive tried this instead of my own modifications in #3 and the votes get saved ok but the voting widget on the node doesnt have any labels, their order is changed and the cancel button is gone
the settings for the respective tags are to show the widget title and allow undo and i resaved the settings form, but still the same
i never tested the patches from jghyde but they look the same
i dont have more time to review this now, if it helps i can attach my copy of the patched module that works for me
i wont reopen the issue because im not sure about where the problem is