Posting as a separate issue per request at http://drupal.org/node/1512550
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 displays, toggling the jump menu and main menu on and off via CSS depending on screen resolution - works nicely, thank you!
From @Robin Milette:
What you are describing has more to do with POST limits.
Right now I'm doing my best to work around the problem by using the block configure link and changing weights in the db - pretty painful. I understand that this problem may be difficult to reproduce, so reach out to me if you need server access or if there's a code change to try. Thanks!
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | jump_menu_problem.txt | 16.95 KB | bcobin |
| #8 | jump_menu_OK.txt | 2.61 KB | bcobin |
Comments
Comment #1
doublejosh commentedIt's possible that because you have a multi-site the block deltas are not specific enough.
They do get a theme column in the DB, but I wonder if there is a conflict that's failing.
EXAMPLE...
Comment #2
bcobin commentedThanks for chiming in, @doublejosh - I'm not sure exactly what you're driving at, although as primarily a user (not a developer), that's not surprising.
As a workaround, I now manage blocks by going to the configure link directly to assign regions and I've gotten into the habit of changing block weights in the database directly using phpMyAdmin, which is actually much faster than waiting for the block page to load - although certainly much less convenient.
Again, with the module disabled, block weight changes save fine - with Better Jump Menus enabled, they don't update nor save. It is a puzzlement...
Comment #3
doublejosh commentedMight recommend using Features and altering block weights via code. This is pretty much required, when blocks from from various contexts.
I'm not a user of multisite, so this is fresh territory. Though this conflict really shouldn't exist due to separate databases.
Can you include some examples of block deltas with a multi-site setup?
Any new thoughts?
Comment #4
bcobin commentedThanks for the response, @doublejosh - much appreciated!
Perhaps I should have been clearer: the issue has nothing to do with Jump Menu functionality per se - the jump menus work just fine, thank you! (And I mean that.)
Rather, there's something in the module that interferes with saving changes to blocks from the main block page. Changing block assignments and weight has now become a two-step process; first, changing theme and region assignment by using the configure link on the main block page (which does not provide a provision for weight) and, secondly, altering the weight directly in the database using phpMyAdmin. And of course, blocks can only be changed one at a time this way.
The Master site (which provides default block assignments) has a large number of blocks, so whenever I create a new site, I now need to remove the blocks that don't belong one by one, which is super-tedious.
With Jump Menus disabled (which I can't really do now because I'm using it on all the sites on the network), everything works normally, even if it does take a really long time to save the blocks page, which I suppose is to be expected.
I'm pretty certain that this has nothing to do with Domain Access, save for the large number of blocks involved in having multiple sites. It looks like a timeout issue more than anything else.
There is a silver lining here, though: once I got the hang of searching for blocks in phpMyAdmin by using theme and region criteria, changing the weights in the database is much faster than dealing with the block page, so it's not all bad!
Perhaps this will help to shed more light on what's going on... thanks again for your response and your work on the module, which rocks!
Comment #5
doublejosh commentedWould like to figure this out.
This module overrides the output function for select elements, which effects all selects. It's the only way to get at adding classes to options. Can you peek at the HTML output of
<select>elements within the block edit screen before and after enabling this module.Comment #6
bcobin commentedThanks for following up on this, @doublejosh - much appreciated.
As per earlier post, I'm using Jump Menus to provide menus for smaller screen sizes, so disabling the module on this particular multi-site would break tablet and phone menus for about a dozen different sites. I'll try to get to this at off-hours; shame I didn't know a few days ago where I took the sites offline for much of Memorial Day for a CiviCRM upgrade... Oh, well!
There's no issue on the (smaller) development version of the site, so I need to do this on the big enchilada. Will keep you advised and thanks again for following up - looking forward to squashing this!
Comment #7
doublejosh commentedYou could compare the HTML output of the select elements on your block edit page to the output of the same elements on a fresh Drupal install.
Comment #8
bcobin commentedThanks, @doublejosh - I'm attaching here the HTML output for one block row from the block edit page from the problem site and another from the development version. There are fewer sites/themes on the development site, but the two are wacky different when it comes to weight. Perhaps this will help?
(Jump Menu is enabled on both sites, BTW.)
Anyway, thanks again for looking into this!
Comment #9
bcobin commentedJust received notice of this, which I will be testing today. https://drupal.org/node/1744692
It's possible that Jump Menus is simply the "straw that broke the camel's back" when it comes to the amount of blocks the system can handle and the issue has nothing to do with the module per se - will report back soonest... thanks!
Comment #10
bcobin commentedYup - looks like it's a max_input_vars issue and has nothing to do with the module per se.
Sorry for the wild goose chase and thank you for following up on this - you may close the issue and thanks for the terrific module!
Comment #11
doublejosh commentedOut of curiosity did you have TONS of menus and themes, so that Jump Menu was generating a huge number of potential blocks?
Comment #12
bcobin commentedAbout a dozen sites, each with its own theme, so when you say "tons," I suppose that's a relative term. All told, the block table shows over 13,000 rows (which includes, of course, system blocks) so I guess that would qualify as "tons."
(Don't try this on anything less than a dedicated server!)
I think Jump Menus really happened to be what put the system over the edge when it came to the POST array and limit on the max_input_vars value, so the problem had nothing to do with the module per se.
Thanks for your attention here and, of course, for the terrific module - by showing and hiding the menus via CSS, making the sites adaptive is much easier! Thanks much!