Previously hard coded size of 1MB meant any file larger was excluded
from recipient emails - often confusing for CMS admins configuring an
advanced use case for a userform, expecting to recieve files to begin a
business process external to the website.
The configuration has been made to support PHP 'shorthand byte values'
https://www.php.net/manual/en/faq.using.php#faq.using.shorthandbytes
in the configuration option. This give flexibility around oddly
specific limits, but can also be used to set as 0, disabling attachments
Tests are updated to set up a known state before testing, as to be able
to accurately assert the results. One should test the class they intend,
not an Injector service of some unknown element.
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()
Passing $emailData and $attachments array to the existing hook, updateAfterProcess
In this case it will give more flexibility for the extension to do
additional cleanup process after the emails has been sent.
If an email send() generates any errors such as invalid template or API exceptions then capture the error in the logs rather than displaying the error to the user.
It's not uncommon to want to override or enhance some functionality in vendor code that doesn't have extension points, so we should avoid the `new` keyword when instantiating injectable classes from the module.
