Gravity Forms 3.0 improves its honeypot and changes the hidden field autocomplete value to new-password. Recent 3.0 fixes also address cases where customized submit buttons could interfere with honeypot and reCAPTCHA v3 behavior, and where API save-and-continue submissions could fail with the honeypot enabled. A real user may be rejected because a password manager fills the hidden field, a cached token is stale, custom JavaScript bypasses expected initialization, or a WAF changes the request. Disabling spam protection removes evidence and protection at the same time. A safer diagnosis correlates browser behavior, request fields, Gravity Forms logging, spam reason, CAPTCHA score, entry state, and confirmation.
Use this when valid Gravity Forms 3.0 submissions disappear, become spam, fail after a custom button change, or behave differently with AJAX, reCAPTCHA v3, password managers, or save-and-continue.
Quick answer
Enable Gravity Forms logging for a short, redacted test window and create named fixtures for normal typing, browser autofill, password manager, custom submit button, AJAX validation retry, reCAPTCHA v3, save-and-continue, and an intentional bot pattern. Preserve the request and classification reason. Fix the first layer that diverges, such as duplicate handlers, hidden-field autofill, stale token, custom markup, or WAF mutation. Keep at least one anti-spam control active while testing.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Normal user | Typed valid entry | Accepted once |
| Password manager | Autofill enabled | Honeypot remains empty |
| Custom button | AJAX and reCAPTCHA | Token and submit run once |
| Bot fixture | Hidden-field or speed signal | Classified with reason |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Enable short-lived redacted logging | Record form ID, Gravity Forms version, honeypot setting, CAPTCHA feed, custom submit-button filter, AJAX state, cache rules, WAF rules, and active browser extensions. | Legitimate typing, autofill, password-manager, mobile, AJAX, and retry fixtures create one expected entry. |
| Run valid-user and bot fixtures | Run valid-user fixtures with typing, autofill, password manager, mobile keyboard, slow completion, fast completion, validation retry, and a second tab. | Intentional bot fixtures remain blocked or classified with an understandable reason. |
| Find the first divergent layer | Capture hidden-field state, CAPTCHA token and score when available, serialized request, response, Gravity Forms log reason, entry or spam record, confirmation, and downstream feed. | Custom buttons, honeypot, reCAPTCHA, save-and-continue, and downstream feeds execute once in the intended order. |
| Repair button, token, or autofill behavior | Compare custom and default submit-button markup, event counts, token creation time, request time, cache age, and API or save-and-continue code paths. | Temporary logs and test entries are removed or retained according to the documented evidence policy. |
What to check first
- Record form ID, Gravity Forms version, honeypot setting, CAPTCHA feed, custom submit-button filter, AJAX state, cache rules, WAF rules, and active browser extensions.
- Run valid-user fixtures with typing, autofill, password manager, mobile keyboard, slow completion, fast completion, validation retry, and a second tab.
- Capture hidden-field state, CAPTCHA token and score when available, serialized request, response, Gravity Forms log reason, entry or spam record, confirmation, and downstream feed.
- Compare custom and default submit-button markup, event counts, token creation time, request time, cache age, and API or save-and-continue code paths.
- Repair the narrow integration, retest intentional spam, then remove temporary logs and document the final false-positive and false-negative behavior.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because a cache purge, scheduled action, retry, or deployment can change the evidence between tests.
- Test the real browser and downstream record, not only an admin preview or isolated API call.
- Close the task only after the public workflow, server-side record, and relevant delivery or analytics system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
form=17
fixture=password-manager-autofill
honeypot_value=empty
recaptcha_token_age_ms=1840
submit_handlers=1
entry_status=active
spam_reason=none
confirmation=shown
Why this usually happens
- A password manager or autocomplete engine fills a field intended to remain empty.
- Custom button code prevents the current token or honeypot initialization path from running.
- AJAX replacement attaches duplicate submit handlers or reuses an expired CAPTCHA token.
- A WAF, cache, or optimization layer modifies the request before Gravity Forms evaluates it.
Decision rule
Do not disable all spam protection to make one form pass. Keep protection active, preserve the classification reason, and fix the browser or integration path that makes a legitimate fixture look automated.
Production verification checklist
- Legitimate typing, autofill, password-manager, mobile, AJAX, and retry fixtures create one expected entry.
- Intentional bot fixtures remain blocked or classified with an understandable reason.
- Custom buttons, honeypot, reCAPTCHA, save-and-continue, and downstream feeds execute once in the intended order.
- Temporary logs and test entries are removed or retained according to the documented evidence policy.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Enable short-lived redacted logging
- Run valid-user and bot fixtures
- Find the first divergent layer
- Repair button, token, or autofill behavior
- Retest protection and remove debug data
Mistakes to avoid
- Changing production code, form fields, webhook endpoints, cache settings, or security limits before preserving the failing fixture and current configuration.
- Treating one clean dashboard status as proof even though the browser, PHP process, database, delivery provider, and downstream record have not been reconciled.
- Testing with a different form, role, locale, order state, entry shape, plugin version, or cache state than the workflow users actually reach.
- Leaving debug logs, temporary endpoints, broad permissions, copied secrets, or test notifications active after the verification window closes.
Questions teams ask during testing
Can I test this directly on production?
Read-only checks can be appropriate when access is controlled and output is redacted. Make a backup first, use a named canary record, test state-changing work on staging, define rollback, and schedule any production change for a monitored window.
How do I avoid a false positive?
Match the exact version, request path, form or order ID, role, locale, cache state, and integration path. Repeat the same fixture before and after the change, then compare the saved evidence rather than relying on memory.
What evidence should I keep?
Keep the UTC time, site and plugin versions, fixture ID, expected result, actual result, relevant logs, configuration snapshot, change made, rollback point, and final verification. Remove passwords, tokens, payment details, and personal data.
When should I bring in a specialist?
Escalate when checkout, payments, lead capture, security, customer email, accessibility, or several integrations are affected, or when the safest next step is unclear. A concise evidence packet reduces diagnosis time.
What to tell the client or owner
Give the owner a short evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected and actual result, logs, change, rollback point, final result, owner, and next review date. Redact credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP trace the Gravity Forms spam false positive.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references