Closed GuySartorelli closed 2 years ago
Technically you could use the following then roll your own implementation from there for the scripting. Either way marked as an enhancement for the future π.
//For Recaptcha v2
Requirements::block('undefinedoffset/silverstripe-nocaptcha:javascript/NocaptchaField.js');
Requirements::block('NocaptchaField-lib');
Requirements::block('NocaptchaForm-{field_id}');
//For Recaptcha v3
Requirements::block('https://www.google.com/recaptcha/api.js?render=' . urlencode($siteKey) . '&onload=noCaptchaFormRender');
Requirements::block('undefinedoffset/silverstripe-nocaptcha:javascript/NocaptchaField_v3.js');
Requirements::block('NocaptchaForm-{field_id}');
Ohhhh I forgot you could block resources! Thank you, that gives us a workaround in the meantime π
The way the javascript is handled in this module currently is very opinionated - by using a submit event handler, it makes it difficult for project-specific on-submit code to be handled correctly without interfering with the captcha stuff.
If you could make adding javascript optional, then situations like that can be handled more easily (project code will have to handle the frontend) while still taking advantage of all of the php setup this module provides.
We had been working around this by intercepting the submit function back in 2.1.0, but 2.1.1 changed the way that was handled and broke our forms so we can't use 2.1.1 or newer as it stands.
My proposed solution is that when the configuration is set by a developer to omit the script, it either
form.submit
The latter would probably be easier to maintain in keeping semver, since that function can change with any changes you make to the field itself - but if you are omitting js entirely you have to ensure that any changes you make to the field won't break project scripts.