The more submissions a form receives, the more submission fields it must
process just to be able to load `getCMSFields`. Arguably submission data
does not belong here, but this is beyond the scope of this patch.
On popular forms it is not improbable to be trying to process 300,000
submitted fields just to test the unique sets of name and title...
however databases have the ability to do this without wasting PHP cycles
and memory, leaving us with a much smaller set to process and hopefully
bypassing one (of several) performance issues with this module.
The consequence of not making allowance for this is that a page in the
CMS suddenly stops saving or loading via web server or PHP (or both)
process timeouts (e.g. saving takes longer than 30 seconds so saving
never happens).
* FIX unrequire fields when they become dataless
When fields that collect input data are changed in configuration via the
CMS to become fields that no longer collect input data (e.g. TextField
-> HTML Block), submitting the resulting form results in a fatal error,
server 500 response, etc. due to trying to check if a field without data
(ever) has data in it.
To circumvent this we can set the required state to false if the field
is being converted to one that does not collect data (which FormField
API conveniently provides a check for).
* Move parent::onBeforeWrite() to top of function
Co-authored-by: Steve Boyd <emteknetnz@gmail.com>
The inputted value is intended to represent megabytes, but is only
multiplied by 1024 - meaning it'd represent kilobytes. This is then used
to compare with the PHP setting number, which is bytes in the range of
megabytes. Kilobytes are always under megabytes, meaning size
comparisons elsewhere in the code are always true.
We should ensure the calculation for validation is correct.
