Created by: Michael ([email protected]) on 2015/03/11 15:06:07 +0000
Votes at time of UserVoice import: 20
Frequently, when I'm editing a complex Matrix field with many block types, I'll run up against PHP's max_input_vars limit, and some fields will simply be lost to the ether.
This can be really frustrating, as it isn't always immediately apparent that some fields were displaced. (For example, if I add a block type in the middle of the list, fields on the block types at the end of the list may simply vanish. I'm not paying attention to those fields, however, so I don't realize it until hours later, when I start seeing "missing property" errors.)
It'd save a lot of grief if Craft could check to make sure POST requests are complete — i.e. that they contain all of the expected fields.
The simplest way I could envision to do this would be for Craft to include two extra hidden fields — one as the first field in a form, and one as the last — and expect that if the first is present, the last should also be present and should contain a matching value.
If Craft detects that some fields may be missing, it could decline to process the request and show me a warning urging me to increase the max_input_vars limit.
How about using a raw JSON body instead of serialized POST fields? I think that would sidestep the whole issue.
I agree. This also becomes an issue if the user has a high max_input_vars but uses sohosin, which implements its own key limit.
As of right now, if the max_input_vars value is too low, when editing a field, the fields is dropped from the DB, as well as all field data. This is a huge issue.
I like the dual hidden field approach that Michael recommends. There could also be an increased recommended setting during the initial Craft CMS installation process? Of course this needs to be weight against security implications. Craft could also detect the number of fields and compare that to the max_input_vars setting, and provide a big warning to Site Admins on the dashboard or header (similar to Craft update notices).
Either way, I imagine this should fail more gracefully, as losing fields and field data without warning is a huge scaling limitation.
We've had this issue a couple of times as well. Saving a complex Matrix field on a server with insufficient max_input_vars resulted in several of the matrix fields getting lost.
This probably also applies to entries with very complex edit tab layouts... Although missing fields wouldn't necessarily cause destruction in that case, some info might not get processed, and the user would never see an error about it.
We've suffered from this issue both while editing complex field types, and when clients are saving pages with much content.
In both cases, content/settings are lost without a warning.
PHP's implementation of handling exceeding of max_input_vars is not the best, as it throws an E_WARNING that you specifically have to search for in the code. So I can confirm it's not a super easy workaround.
See example here: https://stackoverflow.com/a/21601349/1049287
Michael's suggestion sounds good to me, even though there might be some other way to handle it. In any case, it's a serious issue since content is lost without warning.
Increasing max_input_vars helps, but is a bandaid at best and doesn't bring back already lost content.
Craft 3 seems to work the same way in this regard vs Craft 2.
@karlmacklin Thanks for pointing that SE post out - it’s a tiny bit unreliable but certainly a lot better than nothing! Just implemented for the next Craft 2 & 3 releases.
Why thank you good sir!
Most helpful comment
We've suffered from this issue both while editing complex field types, and when clients are saving pages with much content.
In both cases, content/settings are lost without a warning.
PHP's implementation of handling exceeding of max_input_vars is not the best, as it throws an E_WARNING that you specifically have to search for in the code. So I can confirm it's not a super easy workaround.
See example here: https://stackoverflow.com/a/21601349/1049287
Michael's suggestion sounds good to me, even though there might be some other way to handle it. In any case, it's a serious issue since content is lost without warning.
Increasing max_input_vars helps, but is a bandaid at best and doesn't bring back already lost content.
Craft 3 seems to work the same way in this regard vs Craft 2.