Original report by anjjriit

7.x-1.0-dev version give an error when i used "list(text)" as an fieldtype and "Autocomplete for allowed values list" widget and "Allowed values PHP code" for select list.
Its always return zero ('0') value.

Issue originally reported here http://drupal.org/node/1516182#comment-6076986 at the end of an unrelated issue that was already closed.

I'm getting similar results with 7.x-1.x-dev ( 2012-Sep-27 ). I've tried both a static value list:

1|Thing 1
2|Thing 2

And a php based on the sample code given:

return array(
  1 => 'label_1',
  2 => 'label_2'
);
CommentFileSizeAuthor
#3 autocomplete_widgets-1807590-3.patch577 byteschaby

Comments

bleen’s picture

bleen commented

Dave Kopecek ... have you confirmed this issue?

dave kopecek’s picture

dave kopecek
he/him
commented

Yes. It looks like the problem is in autocomplete_widgets.common.inc, in

function _autocomplete_widgets_sort_options(&$options, $instance)

The function is sorting a keyed array using sort($options) rather than asort($options).

Commenting out the code in _autocomplete_widgets_sort_options() "fixes" the issue...of course it doesn't honor the sort preference.

Not sure yet what else calls the sort function so I'm not quite prepared to submit a straight sort()->asort() substitution patch.
Looks like straight sort()->asort() substitutions does the trick.

chaby’s picture

chaby commented
Status: Active » Needs review
StatusFileSize
new autocomplete_widgets-1807590-3.patch577 bytes

same problem too and Dave Kopecek solution seems to do the trick (thank you !).

Indeed, sort and rsort don't maintain indice keys correlations, whereas asort/arsort do it.
As a result, each time autocomplete widgets allowval process is executed, it will populate form state values with numeric value sorted rather than allowed values key...

Here a quick patch from Dave Kopecek tricks but awaiting for a fix applied to the dev branch soon.

thanks

ItangSanjana’s picture

ItangSanjana commented

Patch on #3 work to me. Thanks

regilero’s picture

regilero commented
Status: Needs review » Reviewed & tested by the community

patch #3 seems to do the trick

bleen’s picture

bleen commented
Status: Reviewed & tested by the community » Needs review

lets see if testbot likes the patch in #3

tacoparty’s picture

tacoparty commented

I applied the patch but am still seeing 0 for the fields instead of the data in the field setup.

Here is the section that was changed in autocomplete_widgets.common.inc:

function _autocomplete_widgets_sort_options(&$options, $instance) {
if (isset($instance['widget']['settings']['order'])) {
switch ($instance['widget']['settings']['order']) {
case 'ASC':
asort($options);
break;
case 'DESC':
arsort($options);
break;
}
}

Did I screw up somewhere?

I also noticed this patch doesn't appear to be in the latest dev release but wasn't sure how that works, exactly.

Thanks for any help anybody can give me!

tacoparty’s picture

tacoparty commented

Never mind. I believe this works now for any new data that is entered. I was refreshing the existing view and it was still returning 0. However, when I entered in new information to the form field, it seems to work.

bleen’s picture

bleen commented

This works with the patch from #3? Or it works without needing a patch?

tacoparty’s picture

tacoparty commented

It works with the patch when adding new content. Previous content was still not displaying but I'm not concerned about that since it was a new section anyway.

jromine’s picture

jromine commented
Status: Needs review » Reviewed & tested by the community

Patch in #3 tested and works (on Drupal 7.20).

bleen’s picture

bleen commented

Committed the patch from #3 ...thanks!

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 3: autocomplete_widgets-1807590-3.patch, failed testing.

mustanggb’s picture

mustanggb commented
Issue summary: View changes
Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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