I’ve had multiple problems with Drupal Commerce that had no logical solution. For example saving a published product display would unpublished it. I’d have to go into the database and manually set the status field in two tables back to 1. Linked taxonomy terms were not reflected in the taxonomy item list. Many other bizarre issues.
The solution was so simple and yet so obscure it deserve to be shared. By simply raising the “max_input_vars” in php.ini from 1000 to 2000 we eliminated every editing failure that had defied every other attempt to debug.
I suspect it may also fix our failed attempts to migrate to D8.
Comments
Comment #2
jmarr commentedComment #3
rszrama commentedJust looking into this afresh, it doesn't appear to be a setting that can be changed in runtime. There's no real bug here as far as I can tell, just some terrifically large forms resulting in partial form data being submitted for a Drupal form. I take it you have a lot of fields in these forms that are failing?
I think this should be a documentation task, but wondering where you think the best place to document this might be. e.g. where would you have expected to find a warning about this? Wanna make sure we note it in the right place. : )
Comment #4
bojanz commentedThis is a general core problem: #1565704: Core Web UI interfaces can go over php's max_input_vars. Easy to demonstrate on the modules or permissions pages.
Comment #5
jenlamptontagging
Comment #6
Michael G commentedFor Bluehots cPanel shared host, one may use the cpanel/advanced/software/MultiPHP INI Editor
to set max_input_vars