The order of options is different when the block is displayed with other pages
On the results page, the options appear correctly
This only happens when two options are used, keeping all default settings

See the images attached

Comments

josevitalsouto’s picture

Title: Incorrect order of options in Poll block » Incorrect order of options in Poll
josevitalsouto’s picture

Title: Incorrect order of options in Poll » Incorrect order of choices in the Poll
StatusFileSize
new10.25 KB

The choices also become disordered when clicked "More choices"

amateescu’s picture

Version: 7.x-dev » 8.x-dev
Assigned: josevitalsouto » amateescu
Status: Active » Needs review
Issue tags: +Needs backport to D7
StatusFileSize
new456 bytes

@vitalsouto, assigning issues to yourself means that you will work on (and create a patch for) them :)

Anyway, after I struggled a bit with FAPI, I found out that the problem lies in our call to element_children() from theme_poll_choices().

I will re-roll http://drupal.org/node/939880#comment-4941348 because reversing keys in hook_validate() is not needed anymore after this patch.

josevitalsouto’s picture

Sorry, I'm still learning things here! :)

c31ck’s picture

Patch solved all above problems for me on Drupal 7.8. Thanks.

bleen’s picture

Status: Needs review » Reviewed & tested by the community

This is the correct fix... RTBC

catch’s picture

Status: Reviewed & tested by the community » Needs work

element_children() defaults sorted to TRUE, so we need to explain why we're setting it to FALSE explicitly. Also this makes me wonder if there is somewhere earlier in the process it could be set to FALSE than the theme function? Why not in the form itself?

If that's already been rejected it'd be worth adding in a comment.

Lastly since we're using element_children() directly in the theme function, it'd be possible to use the $sort parameter to ensure these get sorted instead of the #sorted flag, don't have a preference though.

c31ck’s picture

Should we be using element_children in theme_poll_choices() to sort the poll choices? Can't we just add them in correct order in our form definition? When creating a new poll, the 2 choice inputs that are displayed have the same weight value. I created a patch that changes this.

c31ck’s picture

Status: Needs work » Needs review
amateescu’s picture

After a lot of thinking on this, I agree that increasing the weight for each choice is a good option as well, but should be done before adding the choice.

Our current tests don't catch this bug because in _pollGenerateEdit() we specifically assign weights to new choices, and it's obvious that will always work :)

The test-only patch attached removes the hardcoded weights and uncovers expected failures: the initial two choices are reversed. The commented test is intentional, because we're messing with weights in poll_form() and that brings more failures than needed for the purpose of this test-only patch. Anyway, It's untouched in the full patch and it passes on my local dev.

amateescu’s picture

Status: Needs review » Reviewed & tested by the community

Tests behaved as expected, setting to RTBC based on the idea from #8 and because my patch only fixed the current tests.

catch’s picture

Version: 8.x-dev » 7.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

Looks good. Committed/pushed to 8.x, moving back to 7.x for backport.

amateescu’s picture

Status: Patch (to be ported) » Reviewed & tested by the community
StatusFileSize
new1.95 KB

7.x patch.

josevitalsouto’s picture

Title: Incorrect order of choices in the Poll » Incorrect order of choices in Poll module.
webchick’s picture

Committed and pushed to 7.x, thanks! Looks like a nice test clean-up as a bonus. :)

webchick’s picture

Status: Reviewed & tested by the community » Fixed

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