Posted by skyredwang on April 2, 2009 at 5:52pm
10 followers
| Project: | Multiselect |
| Version: | 7.x-1.8 |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Issue Summary
When a user comes back to re-edit the existing list. The list has already been sorted alphabetically. It would be better, if the default preserves the order as the items being generated, then maybe on the interface provides a sorting button.
Comments
#1
Multiselect does not provide any sorting of the items in the list. The items are fed to this widget via CCK, so the sorting occurs inside the CCK module.
Marking as duplicate for #417328: Sorting.
#2
Thanks for the explanation. Now, I realize that I asked the question in a wrong way.
The problem is: if 'available options' are:
A
B
C
D
E
If user selected those items in this order
B
E
A
Then, when this user revisit editing page again, your implementation automatically displays the list as
A
B
E
So, if the user submit it again, his list becomes
A
B
E
The original selection widget preserves the order, I just thought you might want to keep it.
#3
Again, this is dependent upon the order of items being fed to the widget from CCK. They are displayed in the order they are received. Sorting is not being performed by this widget.
#4
I am running into the same problem. If you feel that CCK needs to pre-order by delta before multiselect to maintain selection order, then what is your work around ....... ? or if no work around exists, can we at least decide on which component in CCK to submit a bug report against?
#5
I have looked into the issue and have determined that multiselect is at fault here.
The problem was that multiselect was ignoring the order of the items in $element['#value'].
I have attached a patch that works well for me. I also removed some dead code.
#6
Nice patch! Thanks for pointing out those issues. Committed to 6.x-1.x-dev. If everyone can test this, and it works OK, I'll get an updated release out in the next day or two.
#7
#8
Automatically closed -- issue fixed for 2 weeks with no activity.
#9
This issue apparently reappears in 6.x-1.4
#10
what version is this patch for? I got 3 out of 3 failed hunks in 1.2 and 2 out of 3 failed hunks in 1.4.
#11
i can confirm that the patch in #5 doesn't work for 6.x-1.4.
#12
Should be fixed again in dev. Might do a 1.5 release today. I have a few other issues to review.
#13
Automatically closed -- issue fixed for 2 weeks with no activity.
#14
It doesn't look like this patch is applied for D7. Can that happen?
#15
Subscribing, I want to see this in D7 port.
Edit: Oh, sorry didn't mean to assign.
#16
Ok,
I had this issue with D7 too, but for me after about an hour of debugging (would help if the theme_multiselect function ever ot called by the way!!) I found the following modification works.
BE WARNED THIS IS AS KLUDGED AS IT GETS
Against version 7.x-1.8 of multiselect
I really don't have the time to install programs (I'm on windows) and create a patch file, but here is my simple modification:
$widget = _multiselect_build_widget_code($options, $items, $element, $required);with this code:
$widget = _multiselect_build_widget_code($options, $items, $element, $required);
//for each selected item ($items are in delta order still), we unset the item from $options (which is in nid/tid order)
//then just re-append it to the bottom of the options array, in order of $items, this fools the FAPI and retains order on edit
foreach ( $items as $item ) {
if ( isset ( $options[$item['nid']] ) ) {
$val = $options[$item['nid']];
unset($options[$item['nid']]);
$options[$item['nid']] = $val;
}
}
I think it works ok, hope it helps, feedback welcome!
#17
Status Update
#18
I went to make a patch out of this, and I can't get it to work against the dev version. Anybody else tested?