Skip to main contentSkip to footer
Plugin Guides

Gravity Forms Spam Protection Without a Captcha

Updated Patrick Schlesinger
ReportedIP Hive plugin guide banner: Gravity Forms spam protection without a captcha

Gravity Forms spam protection without a captcha means checking that a real browser rendered and sent the form, instead of asking the visitor to prove it. ReportedIP Hive does that for Gravity Forms with one switch: a bot’s submission is refused as a validation error above the form, no entry is written and no notification goes out.

How the underlying honeypot and execution proof work is explained in the guide to the form honeypot. This page covers what is specific to Gravity Forms.

Why Gravity Forms needs protection beyond its own honeypot

Gravity Forms has its own honeypot field, and it stops bots that fill every input. It does not stop the second kind of bot, the one that never loads the page and sends a copied payload straight to the site. That bot never sees any hidden field, so it cannot fill one.

A captcha would stop it, but it puts the work on the wrong person: the sender who wants to reach you has to solve a puzzle, while a determined spam operation pays a solving service. Hive’s execution proof asks nothing of the sender. It checks that the submission came from a browser that loaded the form and ran its script.

What happens to a Gravity Forms submission

Submission fromResult
A visitor in a normal browserThe entry is saved, nothing changes for the sender.
A bot that fills the hidden fieldRefused. The address is blocked on the first attempt and, in Community Network mode, reported.
A script that posts directly to the siteRefused above the form. The address is logged but not counted towards a block.
A browser with JavaScript switched offRefused with a message asking to switch it on.

The block after a filled hidden field needs automatic blocking to be switched on, and whitelisted addresses are never blocked. In the Event Log under ReportedIP Hive > Activity, a refused bot appears as “Form Spam (threshold reached)” with the surface gravity_forms.

Why a refused submission is a validation error, not a spam entry

Gravity Forms has a spam folder, and Hive could have filed refused submissions there. It deliberately does not. An entry in the spam folder is a message whose sender was thanked and whose recipient never reads it. If the verdict was wrong, the person who wrote to you believes the message arrived.

Hive uses a validation error at form level instead, the same mechanism Gravity Forms uses for its own checks. The sender sees the message above the form, can read why and can try again. No entry is saved, no notification mail goes out and no confirmation page appears. What Hive refuses never becomes an entry.

How the check fits the way Gravity Forms works

Forms sent in the background

Gravity Forms often sends its forms itself, in the background, without the browser’s normal submit step. Hive hooks into the moment Gravity Forms sends the data, the same place the plugin’s own invisible captcha uses. Background forms and forms that reload the page are covered the same way, and the error appears above the form in both cases.

Forms with several pages

A multi-page form sends every page as a request of its own. Only the last page is the actual submission, so only that one is checked. Moving between pages is never slowed down or refused.

Forms that appear later

A form shown a second time, after a failed validation or inside a popup, arrives after the page has loaded. Hive listens for Gravity Forms’ own render event and prepares the new form again, so a visitor who corrects a field is not refused.

Entries from the Gravity Forms API

Imports, Zapier feeds and REST calls through the Gravity Forms API do not come from a browser, so they carry no proof. Hive recognises them and stands aside, so automations keep working. On older Gravity Forms versions they are handled the same way the Gravity Forms honeypot handles them.

How to switch it on in four steps

  1. Check the plan. The Gravity Forms adapter is part of the Business plan. On a lower plan the switch stays visible and locked, with the plan it needs next to it.
  2. Switch it on. Open ReportedIP Hive > Protection, card Form Protection, and turn on Protect Gravity Forms forms. Form execution proof must stay on as well. Hive clears the common page caches and, for a transition period, still accepts submissions from pages cached before the switch.
  3. Run the self-test. Under Tools > Diagnostics (visible in Expert mode), Run the self-test sends three test passes from your own browser: like a visitor, like the same visitor twice and like a bot. No real form is submitted and no mail goes out.
  4. Watch the log. For the first days, check the Event Log for refused submissions. If you want to watch before you refuse, switch on Report-only mode in the card Blocking & Escalation first.
Form Protection card in ReportedIP Hive with Form execution proof and Protect Gravity Forms forms switched on
The two switches Gravity Forms needs, on a site with the Business plan.
Form protection self-test in ReportedIP Hive with the Gravity Forms adapter active and all three test passes as expected
The self-test lists every form adapter and confirms that a visitor gets through and a bot does not.

With the Professional plan and above, the Computation check on forms adds a small signed task that the browser has to work out before sending, which also stops scripts that copy the field names out of the page. With Community threat check on forms in Community Network mode, Hive also refuses submissions from addresses the community has flagged. Both are explained in the form honeypot guide.

Questions about Gravity Forms without captcha

Does Gravity Forms still need a captcha with Hive?

Against scripts and bots, Gravity Forms no longer needs a captcha once the Hive adapter is on. The execution proof refuses anything that did not come from a browser that rendered the form. The check cannot tell a person from a botnet driving a real browser; for that case the community threat check looks at the address behind it.

Does Hive work alongside Akismet and the Gravity Forms honeypot?

Hive runs alongside Akismet and the Gravity Forms honeypot without conflict. It checks the submission during validation, before an entry exists, so a submission Hive refuses never becomes an entry that another plugin has to sort. Submissions Hive lets through are handled by your other spam tools as before.

What happens to visitors with JavaScript switched off?

A visitor with JavaScript switched off cannot deliver the proof, so the form is refused with a message asking to switch JavaScript on. Their address is logged but never counted towards a block. If your audience often browses without JavaScript, use report-only mode or leave the Gravity Forms switch off.

Read on

The Hive documentation covers bot detection and form spam and caching and compatibility in detail. The Gravity Forms documentation describes the plugin’s own spam settings. All plans are compared on the pricing page.

Get ReportedIP Hive for WordPress

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed