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).
* strings instead of __CLASS__ for translation keys in trait
* use double backslashes for FQN in _t()
* amend missing for double backslashes for FQN in _t()
When calling `duplicate` on a form, a form field, or suchlike, the results
would be that all related items to the thing being duplicated (such as
fields for a form, or options to an editabledropdown) would be duplicated
_twice_; ie. where a form had two fields, it's new duplicate would have
four (each one occurring twice). We have stopped this in a backwards
compatible way - that is the bug was introduced with core 4.1, and this
change leaves the userforms module compatible with 4.0.
Also if the overridded directory is empty - don’t display the template dropdown as this will cause a validation error preventing the user from saving the page.
