Drag and drop interfaces can break either browsers or exceed PHP server limits for forms

By definition, this is not critical because there is a workaround. I removed extraneous tags.

Apologies if I read the summary wrong. My interpretation was that you were able to enable the items by editing directly, but I think you are reporting a related (maybe one and the same) UI issue. I am tragically bad at reading long paragraphs.

There are some similar issues like #2711369: D8: The positioning of menu items within menus is unstable.

It would help the maintainers if you could please add to the issue summary the steps to reproduce in an ordered list. Thank you!

Also:

• Any contrib modules installed?
• Anything logged in watchdog or the PHP error log?

Looks like this is core bug.. I have experienced too..

I tried with fresh install without any contrib module.. and same error occurred.

When you tries to change menu order .. it disabled all other menu items.

I tried same thing on localhost and it worked..

I experienced the same problem.
Creating a new content, then a menu item for that, on saving menu changes, the menu link is set to disabled.
Creating a new content and checking the option for automatically create a new menu item for the content in the main manu, the menu link is created and automatically set to enabled. So it's visible on the menu.

But entering the main menu to manage it, on save, the link is set to disabled again.

Seeing the same issue on 8.1.9. How has it not been resolved yet? Is there some sort of complicated reasoning behind this? It seems like this is a pretty core capability (to be able to drag and reorder AND SAVE) when it comes to rearranging menu items. It's just a pain to keep modifying weights just to 'squeeze a few objects between others'.

Any tips on how to most effectively do that are welcome.

Steps to reproduce error:
1- Create new menu item
2- Save new menu item
3- At Edit Menu screen, click on Save button (with or without making any changes)
4- All items will be disabled

I experienced the same problem in my host but in my localhost it work well.

I tested the steps described in #11 and the described behaviour does not happen in on 8.3.x nor does in in 8.2.x.

Currently experiencing this on 8.2.1.

Modules installed:

- admin toolbar
- auto_entityqueue
- config_update
- ctools
- entityqueue
- features
- flexslider
- libraries
- pathauto
- superfish
- token

Steps:
1. Add new page content type
2. Check "provide a menu link" option box
3. Save page

At this point the page is saved and shows up in the menu

1. Go to Structure -> Menus
2. Edit the menu <-- New items show up as enabled here
3. Uncheck enabled box for HOME menu item to disable
4. Click save <- At this point all menu items now show as disabled.
5. Check boxes to enable all menu items
6. Click save <-- At this point the page reloads showing all items STILL disabled

Oddly enough the top level menu items are still showing in the menu even though they are marked in the menu management as disabled.

Watchdog output from my drupal install while adding content and updating the menu:
75 11/Oct 10:00 notice content hub_page: added Hub 1.
76 11/Oct 10:00 notice content hub_page: added Hub 2.
77 11/Oct 10:01 notice content hub_page: added Hub 3.
78 11/Oct 10:01 notice content hub_page: added Hub 4.
79 11/Oct 10:01 notice content hub_page: updated Hub 2.
80 11/Oct 10:02 notice menu Menu Main navigation has been updated.
81 11/Oct 10:05 notice menu Menu Main navigation has been updated.
82 11/Oct 10:07 notice menu Menu Main navigation has been updated.

This should be critical as this issue cause loss/corruption of stored data.

@MarcoDeJong

It may be, but I cannot reproduce it on a newly-installed D8 site.

For anyone experiencing this issue, it is super-important to have a clear, numbered, list of the steps to reproduce in the issue summary. It is important to put the steps in the issue summary rather than in a comment, because contributors are busy people and don't always have time to read essays or to watch screencasts.

Looking at #7, environment details may come into play so it would help to mention the version of PHP and other platform details.

For example, the steps in @zenphp listed in #16 are a step in the right direction. But as I mentioned above, it is better to put them in the issue summary. I could not reproduce any of the symptoms seen in #16, with or without Token installed.

• At some point, the Token module was mentioned, but not its version. Token is in Beta. There could be a common contrib module affecting all sites. That is why it is important to find the minimum conditions that produce the bug.
• No errors were logged anywhere? Really? It's possible. But there should be a mention as to whether the browser console, Drupal's watchdog and the PHP error log have been checked for anything.

I realize this is a serious problem for those affected, but we need a better error report. I am going to make this critical but mark it postponed on needing more info. Please add some!

One more thing:

Using the browser dev tools, you can see the data that was posted to the server and what was returned. It would be good to see both of those things.

Okay, I found out what was causing this in my instance, and it might be worth looking into for others. Our staging/production servers have the Suhosin hardening patch set for PHP installed. There are settings in there that limit the length of variable names introduced via GET, POST, COOKIE and REQUEST, and the default lengths are set to 64 characters. In the Edit Menu screen (the bulk drag and drop link list with enabled checkboxes) many of the components are now identified with UUID's prefixed with plugin identifiers. These array index values exceed the 64 character limit allowed by suhosin, and are stripped out of the incoming request. By default there are no logs of this, it appears to be a completely silent action. Drupal interprets these missing items as 0 or false values, causing the unpredictable behaviors here.

So check to see if you have Suhosin installed, and if so try the following configuration settings:

suhosin.cookie.max_array_index_length 128
suhosin.cookie.max_name_length 128
suhosin.cookie.max_totalname_length 512

suhosin.get.max_array_index_length 128
suhosin.get.max_name_length 128
suhosin.get.max_totalname_length 512

suhosin.post.max_array_index_length 128
suhosin.post.max_name_length 128
suhosin.post.max_totalname_length 512

suhosin.request.max_array_index_length 128
suhosin.request.max_totalname_length 512
suhosin.request.max_varname_length 128

These have cleared up the problem for me.

Version 8.2.5 has same issue with same reproduced steps in #11.

Confirm that in Drupal 8.2.6 I still had the main menu not saving settings and resetting.
With zenphp's fix in #21 I modified Suhosin's settings via drupal's htaccess file eg
inserted #21 adjustments with addition of php_value after

<IfModule mod_php5.c>
php_value suhosin.cookie.max_array_index_length 128
...

Stephen_WTD

Would you post the exact code you added? I can't the earlier #21 adjustments and it looks like, if I'm reading your comment correctly, your code might be truncated? (...)

To do this in the .htaccess file you would need a block similiar to:

<IfModule mod_php5.c>
  php_value suhosin.cookie.max_array_index_length 128
  php_value suhosin.cookie.max_name_length 128
  php_value suhosin.cookie.max_totalname_length 512

  php_value suhosin.get.max_array_index_length 128
  php_value suhosin.get.max_name_length 128
  php_value suhosin.get.max_totalname_length 512

  php_value suhosin.post.max_array_index_length 128
  php_value suhosin.post.max_name_length 128
  php_value suhosin.post.max_totalname_length 512

  php_value suhosin.request.max_array_index_length 128
  php_value suhosin.request.max_totalname_length 512
  php_value suhosin.request.max_varname_length 128
</IfModule>

I think that this issue could be closed at this point, it seems that things work as expected when PHP works as expected. It might be worth submitting a note to the install documentation that Suhosin cannot be used with default settings though, or adding settings similar to these to the default htaccess provided with D8.

Yeah suhosin is a common problem in Drupal projects. The permission page has a good history of being broken due to that.

I would argue we should close this as "closed (worked as designed)", but maybe we could add some hook_requirements() warning, when suhosin is configured to not allow to many POST variables.

Drupal 8.3.5: Re-ordering menu items then save, or flushing all caches was setting all menu items to disabled! I had to edit them and enable one by one.

Changing PHP version from 5.6 to 7.0 has fixed this problem for me!

This problem is surely experienced by a wide swath of Drupal 8 users.

The fix suggestion at #25 did not work for me.

sprite,

We had a similar issue on a very big menu, and had to update the following PHP input limit settings:

max_input_vars=10000
max_input_nesting_level=1000

I'd suggest looking at just how many input_vars/input_next_levels are attempting to be posted and add a buffer rather than just blindly changing these values.

@henrysingleton

changed php to:

max_input_vars=11000
max_input_nesting_level=2000

The changes did not fix the problem.
I've experienced the inability to make changes on the menu item list page bug on every server and every D8 install since starting to use D8.

Is suhosin installed? How many menu items are in play?

We have #1565704: Core interfaces can go over max_input_vars and #1203766: With large number of permissions /admin/people/permissions becomes unusable as well as #2507019: Determine how much POST truncation protection is needed and add tests for it and several other issues related to this, usually about max_input_vars rather than suhosin. I think a hook_requirements() would be worth doing for either or both, would need to write a handbook page with troubleshooting steps and mitigations to link to.

We should also really look at modernizing these interfaces (i.e. could we AJAX-update temp store for drag and drop? the permissions page has usability issues already which mirror the max_input_vars problem).

The php.ini modification mentioned in #30 did the trick for me.

I'm using admin toolbar which I beleive adds quite a few items to the administration menu. No issue with the menu until I added a custom item (link) to it. All my modules and core were up to date when I noticed the issue.

I initially tried what was done in #30. But had to keep increasing values with no fixed result.

So while #30 worked for some folks - Suhosin adjustment did work for me.

What is missing from the discussion is what safe limits for each of these variables from a security standpoint - they are limited for a reason. It may be out-of-scope for this page - but seems relevant.

Re-titling this and changing it to a task.

I think the silent loss of data and lack of workaround in some cases means this should probably stay critical, however we should just work on warning people about the php.ini settings in this issue, and promote the interface refactoring issues to major.

Thought about it some more, I think we should try to fix the root cause here, it may actually be easier than warning, especially for drag and drop.

Updated the issue summary again.

Is there a solution/workaround to this? I encountered it on a site with approximately 300 menu items. When I saved, the last 50 got disabled. Only solution is to edit each item individually and change weight from there.

When I increased max_input_vars from 1000 to 3000 the error disappeared.

..at the end of the day: yes, it is a 'one of those' basic php freshly installed settings that needs to be handled -- given that scale of your project (all the modules and awesome magic tools that we install...)

What 'Drupal' could do:
a. give a related notice during site install.
b. give related notice on Status page of low settings, such as these..

Thank you andeers #42
This :

When I increased max_input_vars from 1000 to 3000 the error disappeared.

did the trick.

I'm wondering, could we add a feature which validates the amount of form elements which are sent via POST? If this is hit, don't save anything?

it would be more beneficial to have some calculation based off of php's 'current' max_input_vars setting and the number of form elements that could be output before any page load. Problem is having a way to be able have a form be aware enough that what it's about to render is just going blow out these related memory settings. Ajax form's (ie: forms with multiple field adds..) will compound that problem in all situations..

this along with my previous comments..

could we add a feature which validates the amount of form elements which are sent via POST? If this is hit, don't save anything?

I think the easiest way to do this is to add a hidden element to the end of the form (or move the existing form_id or form_token element to the end, via e.g., giving it a large #weight). Then that would be empty in a situation where there are max_input_vars or more elements before it. At a minimum, that would result in the form not saving anything.

If we do this via a new hidden element, then we could also add a friendly validation error based on it being empty (rather than piggy backing on the errors that happen when form_id or form_token are empty).

Note that FormBuilder already has this code in it:

if ($ajax_form_request && !$request->request->has('form_id')) {
  throw new BrokenPostRequestException($this->getFileUploadMaxSize());
}

But that only runs during AJAX submissions, and it's assuming that the lack of a $_POST['form_id'] is due to a file upload maximum, as opposed to the other ways that POST truncation can occur.

it would be more beneficial to have some calculation based off of php's 'current' max_input_vars setting and the number of form elements that could be output before any page load.

It should certainly be possible to count the form elements that we're outputting during the initial form render, but then what do we do when that counter exceeds max_input_vars? At a minimum, I guess we can output an error message with a link to some documentation? The tricky part is that the correct action to take is situation-dependent. It might be to increase the setting. Or it might be to decrease the form size in some way (via whatever Drupal configuration or contrib modules allow for that).

Detecting this somehow is a good idea, but seems more appropriate for #1565704: Core interfaces can go over max_input_vars. However I think we should try to actually fix the drag and drop interface in this issue so that it doesn't run into the problem at all - i.e. change the weight select to a text field or similar.

The current issue title is "Select lists on drag and drop interfaces can break either browsers or exceed PHP server limits for forms".

i.e. change the weight select to a text field or similar

How would that improve the "or exceed PHP server limits for forms" part?

Is the suggestion then to re-scope this issue to just "Select lists on drag and drop interfaces can break browsers"?

because it's not just select lists.. it can be caused by any and all form elements with or without ajax.. I can't see how sticking our head in the sand to one aspect will help this issue that i know has been a concern -- forever, not just for drupal 8, 7, 6...

there are other linked issues to this one as is. as well as other non-linked. certainly, if we search we'll find more like reports..

max_input_vars tag

@effulgentsia if I understand correctly, each option on a select list counts as an input variable, so when we show say 100 menu items each with a select list containing 100 weight options, that results in 10,000 input vars.

If however each of those select lists was a text field, it would be only 100 input vars.

> @effulgentsia if I understand correctly, each option on a select list counts as an input variable, so when we show say 100 menu items each with a select list containing 100 weight options, that results in 10,000 input vars.

That's news to me? A single-value select sends only one value to the server? Actually building the form/html is a different story of course and does require more memory/time than a textfield.

hmm you're right of course it doesn't send everything in the select list, in which case we're just dealing with items x fields (but still managing to go over).

Re-titling and downgrading to major. I think #1565704: Core interfaces can go over max_input_vars is the actual critical issue here.