CAPTCHA validation fails on entity forms: extractFieldInformation() does not detect fields in containers/fieldsets

Problem/Motivation

When Mosparo is used via the CAPTCHA module (mosparo_captcha) on entity forms (e.g. node_*_form), server-side validation fails with the generic CAPTCHA error and the log message "The form is not submittable." from mosparo_captcha.

The same Mosparo connection works correctly on simple core forms such as user_login_form.

The root cause appears to be in MosparoService::extractFieldInformation(). That method does not correctly discover fields on typical Drupal entity edit forms:

Entity field wrappers use #type => container. The method only inspects direct children of containers. The actual input is under widget, so fields like field_member_email are never added to the field information array used for API verification.

Field Group / fieldset elements use #type => fieldset or details, not container. These are registered as a single field entry (e.g. group_main) and their nested fields are not extracted recursively.

As a result, the Mosparo frontend widget validates visible inputs in the browser, but mosparo_captcha_captcha_validation() calls prepareFormData() with an incomplete or empty set of required/verifiable fields. verifySubmission() then returns a result where isSubmittable() is FALSE, or required/verifiable field checks do not match what Mosparo verified on the client.

Example: Member registration form node_app_member_form at /register (anonymous user, CAPTCHA point enabled for that form ID). Login with the same Mosparo connection works; node add does not.

Environment: Drupal 11, mosparo_integration + mosparo_captcha, CAPTCHA module, Field Group on entity forms.

Steps to reproduce

Install and enable mosparo_integration, mosparo_captcha, and captcha.
Configure a Mosparo connection and set it as the default CAPTCHA challenge (captcha.settings: default_challenge = mosparo_captcha/mosparo (connection: …)).
Enable a CAPTCHA point for an entity form with multiple fields and Field Groups, e.g. node_app_member_form (or any node_*_form with field widgets inside fieldsets).
Optionally compare with a CAPTCHA point on user_login_form (should work).
As an anonymous user, open the entity create form (e.g. /node/add/app_member or a custom route that builds the same form).
Fill in visible required fields and complete the Mosparo check.
Submit the form.
Expected: Form submits successfully when Mosparo validation passes.

Actual: Form does not submit; user sees the CAPTCHA failure message (e.g. “The answer you entered for the CAPTCHA was not correct.”). Watchdog/log contains: mosparo_captcha: The form is not submittable.

Verification via Drush (optional):

$form = \Drupal::service('entity.form_builder')->getForm($node, 'default');
$fs = new \Drupal\Core\Form\FormState();
$fs->setCompleteForm($form);
$info = \Drupal::service('mosparo_integration.service')->extractFieldInformation($fs);
// field_member_email (and most entity fields) are missing from $info
// Compare with user_login_form where 'name' is present.

On user_login_form, name is extracted with type => textfield. On entity forms, fields with #type => container and widgets under widget are not extracted.

Proposed resolution

Improve MosparoService::extractFieldInformation() to support common Drupal form structures used by entity forms:

1. Recursive traversal of form elements (fieldset, details, container, and other grouping types used by Field Group).
2. Entity field containers: when an element has a widget child, derive field metadata from the widget (and field definition where available), and use the correct value key (e.g. field_name[0][value] for standard fields; special handling for address, link, etc.).
3. Respect #access: skip elements (and descendants) where #access is FALSE, so hidden/admin-only fields are not included in required/verifiable field lists.
4. Align with prepareFormData() / prepareFlatStructure() so server-side field keys match what Mosparo validates in the browser.

Consider adding or documenting use of MosparoIntegrationFilterFormDataEvent only as a fallback; the primary fix should be in field extraction so CAPTCHA, Contact, and Webform integrations behave consistently.

Add functional or kernel test coverage for an entity form with at least one field inside a fieldset and one top-level entity field widget.

Remaining tasks

Implement recursive field extraction in MosparoService::extractFieldInformation()

Handle entity widget containers and common field types (email, string, textfield, textarea, address, telephone, etc.)

Skip inaccessible fields (#access === FALSE)

Add automated test(s) for entity form + CAPTCHA validation path

Verify mosparo_webform / mosparo_contact are unaffected or benefit from the same logic

Update module documentation if integrators relied on workarounds

User interface changes

None expected. End users should only see correct Mosparo/CAPTCHA behaviour on entity forms (successful submit when the challenge is passed). No new UI components required for the fix.

API changes

Internal / service behaviour (backward compatible if done correctly):
- MosparoService::extractFieldInformation() would return a more complete and accurate field map for entity forms and nested field groups.
- prepareFormData() would receive correct $elements, improving requiredFields and verifiableFields passed to verifySubmission() without requiring custom code in consuming projects.
Public API:
- No breaking changes to entity/config schema anticipated.
- Existing events (mosparo_integration.filter_field_types, mosparo_integration.filter_form_data) remain available for edge-case adjustments.

Data model changes

None.