Captchas and honeypots don’t seem to work well and/or cause friction to end-users. But I have an idea that could solve this elegantly.
I’m not worried about a form being submitted by bots and solicitors. But if I could stop the admin notifications from going to a client when it’s clearly spam or a solicitation, then all would be well with the world.
If we could use conditional logic to prevent a notification from being sent then we’d have a unique unbeatable honeypot type solution.
Example, IF a URL or the following words appear in any of the form fields (except the “Website” form field) THEN do not send the admin notification. (PPC, SEO, Ads, Warranty, etc)
The keywords might be different depending on the client.
Another additional move might be to not send the notification if a field has more than X characters (sales bots like to add a lot of content in the form fields).
Before heading down that road, try the Gravity Forms Zero Spam plugin. It’s a very simple plugin that stops script-based spammers – funnels them all into the Spam folder in your entries. You can then turn off the honeypot field and remove reCAPTCHA.
Right, warm bodies in seats. In that case, you could do what I’ve done on a couple of sites and hook the gform_entry_is_spam filter to check entries for key phrases / URLs from a blocklist. Pretty easy to set up, and that doco page has a few examples of how to tackle it.
If you’re after a pre-canned solution, take a look at the GravityWiz perk for blocklists. I might be wrong, but I think that one works at the validation level, stopping an entry rather than marking as spam – maybe someone else can chime in here!
There used to be more robust notification conditionals in GF years ago because I have fuzzy memories of setting it up (out of the box) so that a notification is not sent if a URL is added to a form field. Putting that on the general “Message” field where all the bad guys love to stuff the url they are pimping cut out 99% of all spammers and scammers. It was magic. I am now making sad noises I can’t simply do that out of the box anymore.
Right, yes, you can have a rule for “contains” but not “does not contain”, which is a bugger.
I needed to add a blocklist to a new site I’m building, so I’ve spun out the code into its own wee plugin which you can use if you like. Download the zip file and install, or check out the GitHub project. No warranty, no support, minimal features.
My guess here is that you could also use GP Blocklist.
It will allow you to validate a field’s value against the WordPress Disallowed Comment Keys validation.
This plugin allows you to validate a field’s value against the WordPress Disallowed Comment Keys validation. This option can be set for a single field, multiple fields, all fields within a form. If the field fails validation it will display an error to the end user stating that their field contains disallowed words.
OK, no worries. If you return true for the gform_entry_is_spam filter hook, the entry is marked as spam and notifications are not sent – but it’s still saved, you get a Spam filter on your entries listing. Can be handy for recording false positives (but then, you need to wade through the spam looking for them!)
