Afform - Add support for ReCaptcha v2

[colemanw]

Overview

Supports the Recapta2 element in FormBuilder.

Technical Details

Depends on #24862 for Afform to support extensions adding new element types.

Comments

This refactors #24689, moving the code to an extension and making it event-driven.

[civibot]

(Standard links)

• If this is your first pull-request for CiviCRM, please browse CONTRIBUTING.md for information about the development and testing processes.
• If you are reviewing this pull-request, you may wish to consult the test sites and the Review Standards (long template, short template).

[seamuslee001]

This seems like the right direction to me I'm just wondering @colemanw if its worth splitting out the work on the general afform type from the recaptcha work just to try and make things a little mergeable?

[colemanw]

Ok I've broken the Afform part into #24862

[kurund]

@colemanw

Thanks, #24862 looks good.

While checking this PR, I am getting validation error even if the Recaptcha is checked and valid.

Also would be good to rebase other PR is merged.

[colemanw]

Thanks @kurund. I've merged the other PR, rebased this one, and fixed the bug you noticed. I think this is done.

As a followup, I noticed that the validation errors (including this one) don't bubble all the way up to actually get shown to the user. I think we'll need to extend the CRM_Core_Exception class to distinguish between safe messages and debug messages (currently none are visible to users without "view debug output" permission)

[kurund]

thanks @kurund. I've merged the other PR, rebased this one, and fixed the bug you noticed. I think this is done.

Yes, it's working as expected now.

As a followup, I noticed that the validation errors (including this one) don't bubble all the way up to actually get shown to the user. I think we'll need to extend the CRM_Core_Exception class to distinguish between safe messages and debug messages (currently none are visible to users without "view debug output" permission)

I feel CRM_Core_Exception is not passing the errorData correctly. So we might directly need to return the error message.

diff --git a/ext/afform/core/Civi/Api4/Action/Afform/Submit.php b/ext/afform/core/Civi/Api4/Action/Afform/Submit.php
index f9c301cb1b..e2c64b1c37 100644
--- a/ext/afform/core/Civi/Api4/Action/Afform/Submit.php
+++ b/ext/afform/core/Civi/Api4/Action/Afform/Submit.php
@@ -67,8 +67,10 @@ class Submit extends AbstractProcessor {
     $event = new AfformValidateEvent($this->_afform, $this->_formDataModel, $this, $entityValues);
     \Civi::dispatcher()->dispatch('civi.afform.validate', $event);
     $errors = $event->getErrors();
+    $detailedErrors = implode('<br/>', $errors);
+
     if ($errors) {
-      throw new \CRM_Core_Exception(ts('Validation Error', ['plural' => '%1 Validation Errors', 'count' => count($errors)]), 0, ['validation' => $errors]);
+      throw new \CRM_Core_Exception($detailedErrors);
     }

I also think Validation Error is kind of redundant as we also show 'Form Error' before that.

[kurund]

@colemanw

Good merge after test fixes. We can handle the sever error message display separately if you don't agree with the above suggestion.

[colemanw]

@kurund the reason I'm putting errors as an array is because concatenating html with plain text into a string leads to escaping issues. Better to output the array of errors and let the javascript template render the markup.