Menu not changed, no error message displayed (max_input_vars)

Hi donquixote,

Thanks for getting back to me - I appreciate it.

1. I switched back to 6.x-2.2

2. I placed a debug line in menu_editor.admin.inc at line 308, right at the top of menu_editor_overview_form_submit(). The debug line doesn't get called for the menu for which Menu Editor doesn't work, but it does get called for the menus that Menu Editor does work properly. So the submit handler is not getting called. Why would that be?

3. I used HttpFox to trace POST parameters. Both working and non-working POST parameters looked pretty similar to my untrained eye - a bunch of mlid-xxxx for link_title, link_path, description, hidden, weight etc. corresponding to the form contents, and at the bottom:
op = Save configuration
form_build_id = form-xxxxxxxx (some big hex number)
form_token = xxxxxxxxx (some other big hex number)
form_id = menu_editor_overview_form

Any suggestions for the next step?

Thanks again.

So I've placed debug lines on menu_editor_overview_form_validate(), function menu_editor_validate_item() and function menu_editor_overview_form_validate_new_item().

On the errant menu, none of these functions appear to be invoked.

But I've confirmed that they do get invoked on the other menus - the ones that do work correctly with Menu Editor.

So it appears that for this particular menu none of the validate functions are getting invoked.

Do you have any suggestions for the next step to figure out what is going on with this?

Neither _menu_editor_valid_weight() nor drupal_validate_form() are called.

I looked further up in drupal_process_form(), specifically the test immediately after the call to form_builder():

if ((!empty($form['#programmed'])) || (!empty($form['#post']) && (isset($form['#post']['form_id']) && ($form['#post']['form_id'] == $form_id)))) {

$form_id is set to menu_editor_overview_form.

The POST trace shows the form_id as menu_editor_overview_form.

$form['#post']['form_id'] doesn't look like it's set at this point. The test fails and drupal_process_form() exits without doing any work.

If you have any suggestions where to look now I'd appreciate it.

No need for apology about little steps. I am extremely happy to be getting your help on this and have no complaints about the time it's taking.

Yes I think it's the if that's failing.

I tried dpm($form) but ran out of memory so I placed a dpm() for each variable used in the if statement.

i.e.

  dpm($form['#programmed']);
  dpm($form['#post']);
  dpm($form['#post']['form_id']);
  dpm($form_id);
  
  if ((!empty($form['#programmed'])) || (!empty($form['#post']) && (isset($form['#post']['form_id']) && ($form['#post']['form_id'] == $form_id)))) {

I've attached the resultant output, just in case I misinterpreted it but in essence it looks to me as though:
#programmed is empty
$form['#post']['form_id'] is empty

As before I appreciate any further guidance on debugging this.

Thanks for the debugging tips - aside from solving the actual problem this is an extremely useful task for me to get deeper insight into the debugging process and to learn more.

With the menu that doesn't work properly:

form['#programmed'] is bool(false)
form['#post']['form_id'] is NULL

With the menu that works properly, it looks like drupal_process_form() is called twice for the menu_editor_overview_form:

First time:

form['#programmed'] is bool(false)
form['#post']['form_id'] is "menu_editor_overview_form'

And again for the second time:

form['#programmed'] is bool(false)
form['#post']['form_id'] is "menu_editor_overview_form'

Attached is the screen output if this helps.

So it looks like the if is failing because of the form['#post']['form_id'] being set to NULL.

Please let me know know if you have any suggestions of where to take the debugging next.

After some more investigation it seems this issue may be related to the number of items in the menu, or possibly the size of the data posted when the form is submitted.

I have been able to reproduce the issue on other menus by increasing the number of menu items beyond a particular threshold, whereupon Menu Editor stops working. Then by using the standard menu editor, I can reduce the number of menu items and Menu Editor starts working again.

So I don't know whether this issue is specifically related to Menu Editor, or instead it is more generic. Maybe I'm just hitting it with Menu Editor due to the volume of data it uses?

The menus in question aren't particularly huge with about 120 items. I can't see anything particularly peculiar about the server set up (although I believe PHP 5.3.3 has caused some problems).

I will see what else I can turn up but if there are any pointers for where to continue my investigation I'd appreciate it.

post_max_size is reportedly set to 60M but now I'm not convinced this true given what's happening. Perhaps this is starting to look more like a server issue and possibly nothing to do with Menu Editor per se.

The size of the post data reported by HttpFox is about 28k and I'm surprised that such a small server limit exists - I would have thought I'd have bumped into this before. In any case I will investigate further and report back. As before any guidance gratefully accepted.

And just to reinforce that this could be a server issue, I've run the site on a different server and the Menu Editor works correctly. As before, I will investigate server configuration and report back.

The Apache server was recompiled without Suhosin support and this issue could not be reproduced. So this looks like Suhosin was the cause of this problem. Menu Editor on certain menus generated excessive post fields for this particular server configuration.

Thank you for your help with this donquixote. I appreciate your prompt and informative responses and learnt a lot from them. I hope you didn't spend too much time on this, given it wasn't actually a Menu Editor issue.

This issue continues to affect me on larger sites and my first step now when I run into anything suspiciously like this is to go sort out max_input_vars (although originally for me max_input_vars wasn't the culprit, rather it was Suhosin).

The problem isn't to do with menus per se, although Power Edit will tend to hit the issue frequently because it increases the number of form elements for the menu. I originally encountered the issue with Power Edit but have subsequently run into it on the permissions form which can also get very large.

So I don't think we need anything too complicated to reproduce this - just generate enough input fields to exceed max_input_vars.

I created a little module which does reproduce the issue on demand - it just gets the value of max_input_vars then creates sufficient input fields to ensure the issue occurs.

What's the 'authorised' way to share this little debug module with you? For example I could just tar it up and attach it as a file.

Alternatively we can just use my server - I set up a test environment where we could play with this. I can share the details with you privately if you'd like to give it a whirl. I'm also keen to get involved further - this was one of my earliest 'meaty' issues since getting involved with Drupal and it will be good to work with you again.

Attached as a zip file.

Just enable the module as usual and visit www.example.com/max_vars_form. The module gets the value of max_input_vars and creates that many checkboxes. If you uncheck some of the checkboxes the form will get validated and submitted, in which case it will generate messages telling you the relevant function has been reached. If all the checkboxes are checked you ought not see the messages indicating the problem has been reproduced

Hope this helps and let me know if I can assist in any other way and let me know how you get on.