Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
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.
Comment | File | Size | Author |
---|---|---|---|
#19 | multiselect-preserve_selection_order-421938-19.patch | 1.05 KB | zareth |
#5 | multiselect.module.patch | 2.31 KB | emilymoi |
Comments
Comment #1
attheshow CreditAttribution: attheshow commentedMultiselect 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.
Comment #2
skyredwangThanks 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.
Comment #3
attheshow CreditAttribution: attheshow commentedAgain, 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.
Comment #4
emilymoi CreditAttribution: emilymoi commentedI 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?
Comment #5
emilymoi CreditAttribution: emilymoi commentedI 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.
Comment #6
attheshow CreditAttribution: attheshow commentedNice 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.
Comment #7
attheshow CreditAttribution: attheshow commentedComment #9
mattgilbert CreditAttribution: mattgilbert commentedThis issue apparently reappears in 6.x-1.4
Comment #10
mattgilbert CreditAttribution: mattgilbert commentedwhat 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.
Comment #11
mvci can confirm that the patch in #5 doesn't work for 6.x-1.4.
Comment #12
attheshow CreditAttribution: attheshow commentedShould be fixed again in dev. Might do a 1.5 release today. I have a few other issues to review.
Comment #14
jschrab CreditAttribution: jschrab commentedIt doesn't look like this patch is applied for D7. Can that happen?
Comment #15
Aciid CreditAttribution: Aciid commentedSubscribing, I want to see this in D7 port.
Edit: Oh, sorry didn't mean to assign.
Comment #16
ZuluWarrior CreditAttribution: ZuluWarrior commentedOk,
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:
I think it works ok, hope it helps, feedback welcome!
Comment #17
ZuluWarrior CreditAttribution: ZuluWarrior commentedStatus Update
Comment #18
evanmwillhite CreditAttribution: evanmwillhite commentedI went to make a patch out of this, and I can't get it to work against the dev version. Anybody else tested?
Comment #19
zareth CreditAttribution: zareth commentedGot the same issue and #16 solves it.
So here is a patch for the -dev
Edit : for 7-1.x by the way
Comment #20
alexweber CreditAttribution: alexweber commentedThanks ZuluWarrior, bfcam and Zareth! Committed in c4d426b.
Comment #22
windmaomao CreditAttribution: windmaomao commented#16 solution does work,
however i would think the order for available options should be fixed as inputs. It seems to me, this works first time. But when you go back to change the options again, the order is undetermined again.
I wonder if anyone else see this issue. thanks.
Comment #23
alexweber CreditAttribution: alexweber commentedI'm open to review and commit new patches but unfortunately don't have time to work on replicating and fixing this atm.
Comment #24
Frogtown CreditAttribution: Frogtown commentedWas just having this same problem, but with 7.x-1.9 -- We are using a custom query here to sort our first row (we have 2 fields sorted as one, in alpha order, but this happens even with a single sorted field) -- the second column was also sorting as alpha once back inside of the edit form. This was causing some chaos, because we were using this to propogate printed nodes for a subject guide for our librarians, which, they want in a very particular order, and were overwriting their order with the alpha list. Just patched in #19 and it seems to have solved the problem. Would love to see this get committed in so that the second column maintains the delta order of which items were added in which order. Never seemed to be an issue in D6 before when I ran a similar system.
Comment #25
pjcdawkins CreditAttribution: pjcdawkins commented@Frogtown
The patch in #19 was committed in the latest -dev version back in November (see #20) so the issue should remain 'fixed'. It would be nice if the maintainer included it in a new recommended release, but that should be a separate issue.
(I'm just a spectator)
Comment #26
alexweber CreditAttribution: alexweber commentedThanks!
Comment #27
Frogtown CreditAttribution: Frogtown commentedI must have glossed right over #20, hehe, thanks pjcdawkins. Good to hear :)