Currently, when adding a Honeypot field to Pro Forms, the HTML output heavily exposes its true purpose to automated bots. The wrapper is hardcoded with classes like brxe-brf-pro-forms-field-honeypot, and the label is hardcoded as "Guardian".
Modern botnets easily parse the DOM for keywords like “honeypot” or hidden radio buttons with bizarre labels and simply bypass them, rendering the protection useless.
Current Output Example:
HTML<div class="brxe-brf-pro-forms-field-honeypot pro-forms-builder-field brf-visually-hidden form-group"> <label for="form-field-guardian42" aria-hidden="true"> " Guardian "
The Solution: Please allow customization of the Honeypot field settings (similar to how Native Bricks Forms handles them). We need the ability to:
- Customize the Label and ID (e.g., allow us to name it “Secondary Email” or “Website”).
- Change the Input Type (allow it to be a standard text or email input rather than just a radio button).
- Remove hardcoded
honeypotCSS classes from the wrapper so we can camouflage it among legitimate fields using our own utility classes for visual hiding (like an accessible.sr-onlyclass).
Why this matters: True honeypot security relies on the field looking structurally identical to a real input so bots blindly fill it out. Giving us control over the field’s markup will drastically reduce spam without forcing us to rely strictly on third-party JS integrations like Turnstile.
****And yes AI generated the request after I explained the issue.