Preserve selection order

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.

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.

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?

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.

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.

This issue apparently reappears in 6.x-1.4

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.

i can confirm that the patch in #5 doesn't work for 6.x-1.4.

Should be fixed again in dev. Might do a 1.5 release today. I have a few other issues to review.

It doesn't look like this patch is applied for D7. Can that happen?

Subscribing, I want to see this in D7 port.

Edit: Oh, sorry didn't mean to assign.

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:

1. Open multiselect.module
2. At Line 94, replace this code :
   $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!

Status Update

I went to make a patch out of this, and I can't get it to work against the dev version. Anybody else tested?

Got the same issue and #16 solves it.
So here is a patch for the -dev

Edit : for 7-1.x by the way

Thanks ZuluWarrior, bfcam and Zareth! Committed in c4d426b.

#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.

I'm open to review and commit new patches but unfortunately don't have time to work on replicating and fixing this atm.

Was 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.

@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)

Thanks!

I must have glossed right over #20, hehe, thanks pjcdawkins. Good to hear :)