Upon installing Gravity Forms 2.7, we noticed Gravity Forms’ new anti-spam honeypot code is labeling perfectly good emails as spam.
Can someone share the criteria followed by Gravity Forms’ anti-spam honeypot for labeling an email as spam? We strongly believe it needs to be reviewed and updated.
Until a fix is released, we highly recommend activating and using at all times the new honeypot feature, “Create an entry and mark it as spam.” Without this new feature activated, we would have had a very difficult time tracking down the root cause of not receiving form submittals containing perfectly good emails.
To assist Gravity Forms’ developers, please ensure your honeypot code does not label as spam perfectly good emails when forms are transmitted by clients or customers that are using a VPN service such as Opera VPN, Cloudflare WARP, etc. We believe this is part of the problem. It appears honeypot does not like VPNs There may be other flaws in the code such as labeling perfectly good emails as spam when website developers are performing frontend multi-tests using the same email address.
The TLDR; is that in addition to the existing hidden input, the submission now also uses JS to inject an extra input in the posted data. If the original honeypot input contains a value or the new JS posted value is missing, then the submission is marked as spam or ignored based on the new form setting configuration.
VPN usage has no impact.
Have you cleared your browser cache and the caches of any caching/optimization plugins or services since updating?
You should also check your page for any JS errors, as they would prevent the honeypot JS from running on submission.
For the lay person, can you expand your statement:
Specifically, can you define better the terms “value” and “new JS posted value.”? Or, a couple of form submittal examples that would trigger honeypot to label a form (email address) as spam.
And yes, we did clear our cache and found no JS errors at this time. Going forward, we’ll carefully monitor this.
Will do. Meanwhile, we read the honeypot documentation your shared. Unfortunately, it does not contain anything that would help. Perhaps it can be expanded in the near future?
Also, come to think about it, we can also disable honeypot and use reCAPTCHA instead, which is not triggering this issue.
There may be other flaws in the code such as labeling perfectly good emails as spam when website developers are performing frontend multi-tests using the same email address.