Jump without "Go" Button

You probably should do this with a little bit of jQuery magic that hides the Go button and attaches whatever handler it is that deals with the enter key being pressed in a text field.

This functionality won't make it into Jump, so you'll need a separate javascript file that you either include in your theme or via some custom module.

How about active (needs more info)?

Community - please post your solutions here. Never say never -- a nice solution, preferrably one that would be turned off by default and require an admin to turn it on, would have a good chance of getting in.

Any development on this question? If there is a solution to it I would like to know how its working.
Best regards

Yeah thats not exactly what I am looking for. I already implemented the needed function with a php-snippet, but its alway a hassle to set it up. I think the plugin without the go button would be a bit more handy. If you are intrested youll find the snippet (only for taxonomy) here: http://drupal.org/node/91924

Hey Guys...
Quickmenu module does this by default...(jumps without a button). It will work with any menu, which means to do taxonomy, you'd have to install taxonomy menu.module as well. I just did this setup on my latest site, and it worked like a charm.

Hope that helps.

I think this would be a great thing to add, however, I do not believe in eliminating the current functionality since some people might have js disabled.

I wanted to try and add this functionality, so I borrowed the code from Rob T above and added it to the code of the module:

(line 51)

  $form['#submit'] = array('jump_quickly_form_submit' => 1);
  $form['#theme'] = 'jump_quickly_form';
  $form['#attributes']['class'] = 'jump-quickly';
  $form['#attributes']['name'] = 'jumpquickly';
  $form['jump_goto'] = array(
    '#type' => 'select',
    '#default_value' => '0',
    '#options' => $options,
    '#attributes'=> array('onchange' => "document.location=document.jumpquickly.jump_goto[document.jumpquickly.jump_goto.selectedIndex].value;")
  );

I noticed that js didn't like "jump-quickly" as the name so I had to name it "jumpquickly". However, since I'm not a js guru, I'm not sure how you would pass in the form id number. I do think it's a good idea to allow more than one jump menu per page!

I dunno, there's probably a more elegant way to make this work.

Also, if you're using a relative path, it does some goofy stuff. For example if your link is "user/" . $user->uid and you're on a user page, the link you'll be directed to will be "user/user/uid".

i do not know the module and didn't read everything here ...

but maybe this helps: http://drupal.org/node/313790

@Rob_Feature #9

Hmm, maybe I'm doing something wrong...but I didn't get a select list with this module just a ul. Am I wrong to think you were referring to a standard form select list? Thanks Rob.
P.S. Your podcast rocks!

I have started writing a patch that will be submitted tomorrow that will:

"This patch adds a configurable setting for adding a js file that will turn a jump module select list into a "javascripty" style jumper. If users have js disabled they will still the standard form. This patch depends on the patch from #344054: Jump blocks use delta for id w/ colon"

This patch includes the patch for #344054: Jump blocks use delta for id w/ colon.

This patch now requires hand massaging to apply against the new version of HEAD. Would you like me to re-roll this against HEAD after you commit #284985: Jump menu should default to showing the active page?

Yeah, let's do these one at a time so that the commit messages will show clear messages for each issue. So, let's take care of #284985: Jump menu should default to showing the active page first and get it committed before re-rolling this one.

subscribe

This patch is against head. It includes a new test case to make sure that the js is included when configured to and not included when not configured to. The hook_uninstall has been updated to delete the variable that stores this configuration and some coder recommended fixes have been made to journal.test.

After a quick look, I think the Javascript needs to target the form.jump-quickly since it's possible for the form to appear someplace other than in a block (for instance, it could appear in a View's header or footer if those are set to PHP and jump_quickly() is called from there).

@marcp as per your suggestion the js now targets form.jump-quickly.

@evoltech - thanks for the patch. I sent you some tweaks to get this working for items that are full URLs. This is still not working on IE and Safari, though.

Don't believe the myth of cross platform compatibility with jQuery. I am sure anyone that has not used it is already skeptical, but I have had so much "luck" with it just working across different browsers that I stopped even testing other browsers.

The problem lied with IE and Safari not liking to bind click handlers on option elements. I fixed this by watching the whole jump-quickly form for a 'change' event then pulling out the selected option.

Good call with looking for offsite urls, I didn't even think of that case. I took it a bit furthur and changed the logic to check for any link with a
:// prefix.

I updated the test cases to reflect the location and new name of the js file.

@evoltech - I haven't tried it yet, but from looking at the patch the drupal_add_js() looks like it might need to be moved. I'm pretty sure it belongs at the beginning of jump_quickly_form() so that it makes it in there even when the jump_quickly() API call is made from some custom code in another module or a view header/footer, or custom block, etc.

oops, I incorrectly copied that section of code from the patch you gave me. Re-rolled.

Thanks, evoltech - I'm looking this over. If anyone else in this thread is interested, please try out the patch in #24. One thing that will change before it gets committed is the line in jump.js that says:

    window.location.replace(dest);

will say:

    window.location = dest;

I played with the replace for a while and didn't like the way I couldn't use my browser's back button. So far I've tested on IE, Safari, FF on Windows and FF on Mac.

I confirmed that the JS change you made in #25 works in FF. Just noticed though that if an off site link is the top menu, not selected, is clicked that it doesn't work. I am not seeing an obvious solution to this right off the bat. I was able to get this to work correctly with native js (like in this example). But then there is the issue of getting all of the id's that the jump-quickly form uses, easy with jQuery, but there seems to be problems mixing jQuery selectors and native js selectors. I also tried binding other events to the select element wiith varying results, none really satisfactory. I am at a bit of a standstill.

subscribe

Eagerly awaiting... - Subscribe

this work;
can also replace the original last module;
also I add a first option select in default position when you not have go button;

only defect is that, when use Go button, in the url is applied pathauto, while
with no button the url is standard /taxonomy/term/..);
think is necessary to add some filter in the code of .js file;

for post #10

I tested work but only at first selectionbecause every time add same url;
first selection site/taxonomy/term/20;
after site/taxonomy/term/20taxonomy/term/20
after site/taxonomy/term/20taxonomy/term/20taxonomy/term/20;

also I create new module with ll suggestion;
but interesting know which solution for your code;
also know how to have in the url tha pathalias (only with Go button is applied )

Applied the patch from #24 against the dev version of Jump - working well so far in FF although I agree the 'Back' button not working is a little irritating. Will be checking other browsers soon.

On the buggy side, I'm defining some Jump menus at theme level using PHP (as documented on the module page):

<?php
  if (module_exists('jump')) {
    print jump_quickly('navigation');
  }
?>

and it seems that Jump menus created via jump_quickly don't get the jump.js file pulled into the page. Add a Jump-created Block and wham, it works. Looked through jump.module and yep, sure enough that's what's happening - no drupal_add_js in the jump_quickly section. Since that's just defining a form I don't even know if it's possible to add js there?

There is an easy Ctools style for Views which allows for Jump Menus and the option to hide the Go button.

As quoted from this comment by ofktoubro:

Or you can enable ctools (http://drupal.org/project/ctools) and an extra "jump menu" option will "magically" and undocumentedly (?) appear in you views "Style" options. Choose that "Style" and select "Hide the 'Go' button" in the styles settings and well... that is it!

@JaredAM (#10)

Here's a quick and dirty way to do this with multiple jumpmenus on that same page using hook_form_alter

function my_module_form_alter(&$form, &$form_state, $form_id){
  switch ($form_id) {  
    case (strpos($form_id, 'jump_quickly_form') !== FALSE):
    // give each menu a unique name
     $jump_id = str_replace('jump_quickly_form_','', $form_id);
     $form['#attributes']['name'] = 'jumpquickly'. $jump_id; 
     $form['jump_goto']['#attributes'] = array('onchange' => 'my_module_jump(this.options[this.selectedIndex].value);');
     unset($form['submit']); 
     break;
}

Then in a js file or some inline js for that page, add the following function. I do this in a sep function so I can have a "make a selection" be the first option.

/**
 * Orders admin screen jump menus
 *
**/
function my_module_jump(url){
  if(url != 0){
    window.location = url;
  }
}

OK, after looking at the changes others attempted and thinking about implementation I kind of borrowed a little from everyone and added in configurations (per block).

The following patch should make each block configurable so that you can enable each block as a javascript jump menu or not. It also adds some configuration for specifying text to be used as the first option in the jump menu. like "Select Options" or etc.

Apply this against today's dev release.

Also, looks like marcp has abandoned this, no commits for 14 months. I will open a new issue to co-maintain and hopefully revive this.

@nicholas - Thanks for the patch. I've tried it out on DRUPAL-6--1 and it applies cleanly.

I'm testing with Garland as the theme on Firefox 3.6.13 on Ubuntu.

At admin/build/block/configure/jump/menu-navigation I'm seeing under the "Hide the submit button and use Javascript to automatically jump to the selected menu item" checkbox, there's an empty div with id of "jump-dependent2" that contains an empty fieldset.

If I click the checkbox then I get the next checkbox to appear with another empty div underneath it. Let me know if you can't reproduce on Garland and I'll get you some better steps to reproduce.

Here is a 'mo betta' version. It should take care of the issue you were describing and it also makes the first checkbox disable itself whenever checking the second checkbox.

forgot to set status

@nicholas - This looks great. A few things that we might want to clear up first, though, before committing:

1. We add the jump.js in hook_init(), even if there are no jump menus on the page. Can we fix this to add the .js only if there's a jump menu on the page? I know it's a tiny .js file, but we probably shouldn't send it unless we need it.

2. The two calls to array_reverse() in jump_quickly_form() -- can we just push the select text onto the front of the array without the array_reverse() calls?

3. The endswitch() call and its corresponding starting colon in jump_block() should probably get changed to the standard curly braces.

4. I disabled Javascript in Firefox with WebDeveloper and the jump menus that are configured for Javascript don't work because they expect Javascript to be there. I think we need to fall back to providing the button if there's no Javascript.

Otherwise, this looks great. I like the dependency on ahah_helper since it keeps the code a little bit cleaner.

I think this should take care of those requests. However, I will say that although there is "less js added" by doing it within the hook_block(); it does call variable_get() for every block that gets enabled. I think the "overhead" of doing it through hook_init() is worth it since it reduces calls to the database despite the fact you are doing it everywhere.

Most sites should have js aggregation turned on anyhow, and that would result in a minimal addition of text if they aren't using it.

BTW, if you want me to just commit this to the dev version we can work on it there. It would be easier for you to test it since you can just cvs up.

of course in a new branch as we discussed via email.

Nicholas - go ahead and create the branch(es) as we discussed. I don't see a need to continue this with patches as long as we're putting this in the next release's dev branch.

The sooner we can get a stable 6.x-1.1 release out with just bug fixes the better, too.

This is in the 6.x-2.x branch now, available in cvs. Please test. I am still not so sure about our choice of loading the js within hook_block(), since we are doing a variable_get for every enabled jump menu block.

What do you think marcp. I would truthfully think it better just loaded via hook_init().

@nicholas - We can't just load the js in hook_block() because we are supporting the jump_quickly() API call that could output the jump form at any time. The one place that every jump form winds up going through is jump_quickly_form() -- why not do it there? If that doesn't seem to make sense, then stick it back in hook_init() and I'll test it out.

I guess my concern was more-so that we are making a call to the database for every enabled menu via variable_get() and then in turn running drupal_add_js() for every js enabled menu if we put it there.

If in hook_init() we only make one call to drupal_add_js(), we could also check that there is at least one block set to use js in the database within this function if necessary.

@nicholas - I think we don't need to be so concerned with the variable_get() calls -- they're all cached anyway. Same with multiple calls to drupal_add_js() -- in our case if we hit this 10 times, we're not adding the .js 10 times.

I think the 2 cleanest options are:

1. Add the js in jump_quickly_form() if the jump menu is configured for javascript
2. Add the js unconditionally in jump_init()

I still like #1 better for this, but don't think it's worth quibbling over too much, so #2 is fine with me also.

The main thing is that it needs to degrade so that even if an administrator says a jump menu should be all javascripty, it will show the "Go" button to users without javascript.

The javascript degradation is working great!

@nicholas - What do you think about exposing the empty select option text even for those jump menus that aren't Javascripty? I think it's a nice user interface improvement even when the administrator doesn't want to use javascript.

Moving to 6.x-2.x-dev to facilitate getting 6.x-1.1 released.

yes, I agree with everything you said. The select option should be available despite js being enabled. And yes I did already work out the js degrading a while back. I will do #1 and then alter the select option interface to be available to anyone.

Small problem with hiding the Go button. The first item in my vocabulary displays by default in the dropdown. This is fine - except of course it nixes the onclick() event as it's already displaying... I could add a "Please select..." to the top of my taxonomy but this seems a bit hackey.

jasonabc, I guess the module should supply an option if you want to add a "Please select..." to the top of the select box (if jumping without a submit button (js) is enabled, or even if not). Adding it directly in taxonomy or menu is the worse way we could do it..

Referring to patch #40

Possible to get a patch for D7 as well?
What code changes are at least necessary to use Jump without submit button?

Edit:
Solved for D7 by using Views instead (I'm using Views 7.x-3.7) with Ctools, simply add a block with jumpmenu format. Very easy way to create a jump menu with taxonomy terms as menu items. In the settings you can as well choose to hide submit button.