Better Jump Menus module interfering with all Drupal forms

Wowza. This seems rather unrelated, though I can test to see if I can find a link.

Two possible causes...

1. Block delta too long - #1512656: Block delta too long with some menus
2. Select option form API override goes to far (ASSUMING THIS) - #1491334: Adding classes to select options

Luckily I'm switching to Omega as the next piece of a project, so this will have to get attention if I reproduce it :)

Would you mind looking in your database at the block deltas and posting those containing jump_menu.
This will help debug the issue.

No problem.
From the command line...

Do you have drush? If so, connect to the db with drush sqlc then run this query:
select * from block where module = 'jump_menu';

If you don't have drush, connect like this: mysql --database=YOUR_DB_NAME --host=localhost --port=3306 --user=root --password=root then run the previous query, or get drush cuz it's awesome :)

Suppose you might also be using phpMyAdmin or mySQLworkbench, etc. Just use that query as well.

Any luck?

Do you have a way to view your database? For example your host may have "phpMyAdmin" to make it easy for you to access the data and structure.
Then input the above query or just have a look at your block module.

BTW: This will get some attention.

I have this same problem. Here is my block detail:

70 jump_menu jump_menu_main-menu justintest_com 0 0 -1 0 0 -1
71 jump_menu jump_menu_management justintest_com 0 0 -1 0 0 -1
72 jump_menu jump_menu_navigation justintest_com 0 0 -1 0 0 -1
73 jump_menu jump_menu_user-menu justintest_com 0 0 -1 0 0 -1

justintest_com is my omega theme that's broken.

I don't think the problem is with the block_delta. Those are all well within limits.

To recreate this problem:

1. Install Drupal.
2. Download Omega.
3. Create subtheme, enable, set as default.
4. Go to subtheme settings (admin/appearance/settings/SUBTHEME) > Zone and region config > Content Zone > Regions > Siebar First. Note that width is 3 Columns
5. Downlad and enable jump_menu.
6. Repeat step 4. Note that width is now 1 Column and cannot be updated.

I hope this helps.

Thanks a ton @unclejustin
Know what I need to do. This will get a fix very soon.

I ran into this problem and think I've found the bug. It's caused by a missing type conversion in jump_menu_form_select_options(). Line 325 in jump_menu.module (http://drupalcode.org/project/jump_menu.git/blob/refs/heads/7.x-1.x:/jum...) should be "$opt_value = (string) $key;". On line 337 this gets compared to a value that is cast to string. Since weights are numeric, this comparison will fail and no options get marked as "selected".

Drupal's core form_select_options() in form.inc does not have this bug and renders the options correctly.

I'm curious why jump_menu is affecting this form at all. I see that jump_menu_select() has commented-out code to make the override only affect jump menus, so could you consider bringing that back and letting Drupal core handle all other "select" elements?

That was my plan: moving back to just jump_menu selects. That code was commented out for two reasons...

1. It's based upon a fairly poor test on class attribute.
2. I'd like to generally improve the select form API item.
   #284917: Allow FAPI select, radios, and checkboxes to specify some options as disabled
   #342316: Introduce proper Form API #types for 'option' and 'optgroup', and make #options consistent.

Going to anyway because I'd like to keep this module running clean.

I posted about this on the Omega page last week, because I thought Omega was responsible for a sudden theme freakout I was having, but it turns out to have been the Better Jump Menus module.

After two hours walking through backups to see when the problem happened and what had changed, I concur.

Within an options list the selected item has an attribute selected set to selected to label the option that is the previously selected. For example:

<option value = "1">1</option>
<option value = "2">2</option>
<option value = "3" selected="selected">3</option>

What is happening is a condition was set to compare the $element['#value'] to the $optValue to test if they are equal. However, the === operator is used which tests for type also. $element['#value'] is being cast as a string while the $optValue is always an integer which means the expression never evaluates to true. I following the paradigm of theme_select() in form.inc and cast the $optValue as a string which solves the problem.

Here is the patch.

I can confirm I'm having the same problem. It is also rearranging blocks as well.

Thanks for the patch. It seems to work so far.

Thanks for the patch. Better jump menus reset my menu items to weight -50 when editing a node but the patch in #12 solved it.

Making as critical. This issue with jump menu affects pretty much everything. Block weight, context block weights, Omega region widths and even core settings. It reverts pretty much everything.

Patch does not resolve it for me. Still reverting block weights.

I'm currently finalizing an upgrade to D7 in Omega so I promise this is not forgotten. Sorry for the delay.

Patch does not work for me either. Also changing title to reflect the extent to which this bug affects sites that install it. It pretty much interferes with and reverts any setting page in Drupal. This module is in desperate need of a fix and new release. Judging by the # of 7.x users (not sure if this affects the D6 version) this would be around 200 sites that are essentially broken. Users may not even know why either. It took me a few days of debugging just to identity that this little module was the culprit.

The fix for this has been committed and should be available in the dev release shortly.
Please help by confirming.

The portion of the code which overrides form API selects options will now only effect those which generate ctools jump menus.
This override was done to include extra classes for menu depth #1491334: Adding classes to select options

If anyone is looking for that patch, see this commit diff.

Just tested the latest dev and it appears to have fixed this issue (Others will need to help confirm). However one must install it fresh or uninstall the 7.x-1.3 version, then install the dev version. I have reported the reason why in this separate issue #1606042: Running update.php results in Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation

The change takes advantage of some code that was there all along (commented out) to override select options more carefully.

Thanks @nicoz for the report.
The dev version also includes the new local menu items feature, which calls for new deltas for the module to distinguish them.
I'll tackle that issue over there.

Looked into the mySQL PDOException.
Seems harmless, just updating things with a single query rather than looping makes the DB angry. However the resulting data is fine.
#1606042: Running update.php results in Failed: PDOException: SQLSTATE[23000]: Integrity constraint violation

Great. Sounds like I can roll this out.

It looks like this was committed to the dev version. doublejosh, is there a planned solid release soon?

I was waiting to take care of #1509688: Translated menus display all languages links for this set of features to release. But suppose I should just put out the fixes and features thus far.
http://drupal.org/node/1620226

I never would have guessed the jump menu module was messing up my omega subtheme!

Took me hours going back and forth, restoring databases, rolling back website, just couldn't work out why this was only happening to one of my sites in a multi site setup..... the only one within that setup that uses the jump menu module!

Maybe I should have spotted that.

Sam.

Sorry for the hassle. No problems now though, yes?

Nope, new version works perfect, thanks :)

Sam.

I'm reopening this - the problem is still there and not just on the Omega theme.

I'm doing a mutisite using Domain Access and about ten different themes (two of which are Omega-based); there are over 100 blocks in total. Things were working fine until I reached a certain amount of blocks and then changing regions and/or weights on the admin/structure/block/list page would fail to save. This is regardless of whether block weights were shown or hidden.

No error message - the page just refreshes in its original state.

I'm certain it's this module; when it's disabled, the page saves normally. And I've tried with both the release and dev versions. I'll also mention that the failure is system-wide - it doesn't matter what admin theme is used.

So to summarize, it looks like an issue with mutisite and large numbers of blocks.

Thanks for the cool module - I'm using it for all my sites to handle smaller resolution display - cool stuff! Hoping this can be addressed once and for all - I'll do my best to work around it in the meantime by using the block configure link and changing weights in the db. Rock on!

bcobin, that's an unrelated problem. What you are describing has more to do with POST limits. Can you open another issue?

Sure - happy to do so and sorry for the delay. See http://drupal.org/node/1824804 - thanks!