// $Id: views_plugin_style_jump_menu.inc,v 1.1.2.2 2009/10/28 23:07:48 merlinofchaos Exp $e>

    ...

    // Turn this all into an $options array for the jump menu.
    $this->view->row_index = 0;
    $options = array();
    foreach ($sets as $title => $records) {
      foreach ($records as $row) {
        $path = strip_tags($this->get_field($this->view->row_index, $this->options['path']));
        $field = strip_tags($this->row_plugin->render($row));;
        if ($title) {
          $options[$title][$path] = $field;
        }
        else {
          <strong>$options[$path] = $field;</strong>
        }
        $this->view->row_index++;
      }
    }

Setting the options array like this causes jump menu items to be misplaced when paths are not unique.

Had a quick look at the latest version of this code for D7 and it looks like this will still happen.

Comments

merlinofchaos’s picture

Status: Active » Closed (works as designed)

Yes, that is the design. There's no way around it.

kenturamon’s picture

StatusFileSize
new2.33 KB

How about this? I've made the options array key in view_plugin_style_jump_menu a hash of the field & path appended by the plain path, and updated jump-menu.inc, & jump-menu.js to pay attention to the change where it exists.

mrfelton’s picture

Status: Closed (works as designed) » Needs review
StatusFileSize
new757 bytes

Hope you don't mind @merlinofchaos but I'd like to reopen this issue as it is something of a problem. I believe there are many legitimate use cases where it is desirable to have multiple jump menu items linking to the same url, and it just not possible to do this currently.

Attaches is the views part of the patch from @kenturamon's zip file. This obviously depends on the corresponding patch to be applied to ctools, for which I will open up an issue and post the patch over there.

I think that the approach taken here is pretty clean and effective, and should have no adverse effects.

mrfelton’s picture

Version: 6.x-2.9 » 7.x-3.x-dev

Updating version to D7 dev.

mrfelton’s picture

Cross referencing the ctools issue/patch #1224340: Duplicate option support for ctools jump menus

dawehner’s picture

Personally i would have moved the md5 to the end for accessibility. The important stuff should be at the beginning, nevertheless this would require a change in ctools as well.

Updated the patch to work for summary as well.

dawehner’s picture

Status: Needs review » Fixed

Commited the last patch. Before written a patch which checks for the amount of items + the actual titles.

Commited to 7.x-3.x and 6.x-3.x

Status: Fixed » Closed (fixed)

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

jrust’s picture

Just a heads up that this causes the jump menu to be broken in 6.x-3.x-dev because the associated patch for ctools is still to be ported. Until that happens I've changed:
$key = md5($path . $field) . "::" . $path;
back to:
$key = $path;

jrust’s picture

Status: Closed (fixed) » Needs review
StatusFileSize
new806 bytes

The patch in #6 updated setting the default value for the jump_menu_summary, but not for the jump_menu. The attached patch fixes the jump_menu style to correctly set the default value. It's against the 6.x-3.x branch, but should be easily ported.

monotaga’s picture

jrust, when you say "the associated patch for ctools..." are you referring to #1224340: Duplicate option support for ctools jump menus?

broncomania’s picture

I run into a problem now and i think this is point where it starts. I open already a issue about this problem here http://drupal.org/node/1306934 I think now my post is a duplicate.

How can this problem be solved? I used for the moment #9 to fix my problem but thats pretty not the right way isn't it?

jrust’s picture

monotaga, that's the one.

peterpoe’s picture

Status: Needs review » Reviewed & tested by the community

Tested #10 on the 7.x branch, default value with jump menu displays works fine.

dawehner’s picture

Status: Reviewed & tested by the community » Fixed

Thanks for the patch! Commited to 6.x-3.x and 7.x-3.x

jeanj’s picture

I ran into the same problem with the added hash and found that there was no way to change the created option value link ... wouldn'd it be a better idea to use the "output" (name) rewrite field to build nothing but the option text and the "link" rewrite field to build the option value?

Status: Fixed » Closed (fixed)

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

jelo’s picture

Although the issue has been fixed in views, it appears that the ctools patch has still not been applied. I run views 6.x-3.0 and ctools 6.x-1.10 (latest versions each). I configured a view to use the jump menu display style which now produces "value" output including the hash. Ctools does not clean up this added hash which results in a broken URL pattern in the form of hash::path. #9 shows how to hack the latest views version to fix this.

Should this not have been rolled out together instead of accepting that views and ctools now are not able to show a jump menu in D6 without customization?

amklose’s picture

Issue summary: View changes

@jelo I can vouch for the fact that this is still an issue in 6.x-1.13. I have a jump menu for a blog archive that inserts the year + month argument in the url. However, it was also inserting the hash before the url snippet which led to a 404. I wasn't sure why the hash was being added to the $select key, so in jump-menu.inc, I did some string magic to rewrite the keys to just be the url.

  foreach ($select as $key => $value) {
    $newKeyName = substr($key, strpos($key, '::') + 2);
    $select[$newKeyName] = $value;
    unset($select[$key]);
  }