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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

attheshow’s picture

Category: bug » support
Status: Active » Closed (duplicate)

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.

skyredwang’s picture

Title: Unnecessary sorting » Preserve selection order
Category: support » feature
Priority: Normal » Minor
Status: Closed (duplicate) » Active

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.

attheshow’s picture

Category: feature » support
Status: Active » Closed (duplicate)

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.

emilymoi’s picture

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?

emilymoi’s picture

Status: Closed (duplicate) » Needs review
FileSize
2.31 KB

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.

attheshow’s picture

Version: 6.x-1.2 » 6.x-1.x-dev
Assigned: Unassigned » attheshow
Category: support » bug
Priority: Minor » Normal

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.

attheshow’s picture

Status: Needs review » Fixed

Status: Fixed » Closed (fixed)

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

mattgilbert’s picture

Version: 6.x-1.x-dev » 6.x-1.4
Status: Closed (fixed) » Active

This issue apparently reappears in 6.x-1.4

mattgilbert’s picture

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.

mvc’s picture

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

attheshow’s picture

Version: 6.x-1.4 » 6.x-1.x-dev
Status: Active » Fixed

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

Status: Fixed » Closed (fixed)

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

jschrab’s picture

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

Aciid’s picture

Assigned: attheshow » Unassigned
Status: Closed (fixed) » Patch (to be ported)

Subscribing, I want to see this in D7 port.

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

ZuluWarrior’s picture

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!

ZuluWarrior’s picture

Version: 6.x-1.x-dev » 7.x-1.8
Status: Patch (to be ported) » Needs review

Status Update

evanmwillhite’s picture

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

zareth’s picture

Status: Needs review » Patch (to be ported)
FileSize
1.05 KB

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

Edit : for 7-1.x by the way

alexweber’s picture

Status: Patch (to be ported) » Fixed

Thanks ZuluWarrior, bfcam and Zareth! Committed in c4d426b.

Status: Fixed » Closed (fixed)

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

windmaomao’s picture

Version: 7.x-1.8 » 7.x-1.x-dev
Status: Closed (fixed) » Active

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

alexweber’s picture

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

Frogtown’s picture

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.

pjcdawkins’s picture

Status: Active » Fixed

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

alexweber’s picture

Thanks!

Frogtown’s picture

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

Status: Fixed » Closed (fixed)

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