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.
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 honeypot CSS classes from the wrapper so we can camouflage it among legitimate fields using our own utility classes for visual hiding (like an accessible .sr-only class).
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.
I think the honeypot is more of a prebuilt field for those who don’t know how to set up an honeypot.
As far as i can tell you look the kind of user who is capable enough to handle a custom honeypot with other field types and the field style, attributes and validation settings.
I don’t think the first kind of guy would tinker much with the options you are suggesting.
The honeypot as is is bypassed easily so in the end it is almost useless no matter the user expertise level. Creating a custom one requires to use logic and keep up with it in updates. Bricks native forms allow you to use any field as Honeypot, this is what I mean.
Unless I missing something, the only way to add a proper Honeypot right now is to intervene with code.
You might consider setting the tabindex attribute to prevent tab selection.
Also, usually the correct practice for an hp is to return a success and not an error and then handle the spam according to your needs (see conditional actions)
