Gravity Forms 3.1.1.1 fixes a logging statement that could say a field value was sanitized when certain field types were empty during form display. The message could flood debug files before a visitor submitted anything, hide real validation evidence, inflate log storage, and send a support team toward a firewall or input problem that did not exist.
Use this guide when Gravity Forms logs fill with value sanitized messages, especially on conditional forms, multi-page forms, conversational forms, prepopulated fields, forms embedded more than once, and sites where log volume triggers storage or monitoring alerts.
Quick answer
Update a staging clone to Gravity Forms 3.1.1.1, clear only the test log, and load a marked form without entering or submitting data. Empty supported fields should not produce the old sanitized statement on display. Then submit intentional HTML, control characters, normal text, an empty optional value, and an empty required value. Real sanitization and validation evidence must remain available. Compare request time, form ID, field ID, field type, submitted payload, stored entry, validation result, and log line before reducing any logging level.
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 |
|---|
| Display only | All optional fields empty | No sanitized warning |
| Required empty | Submit marked form | Validation error, no entry |
| Unsafe text | HTML and control characters | Sanitized value and useful evidence |
| Conditional hidden | Branch not shown | No misleading display warning |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Freeze one marked form fixture | Record the Gravity Forms version, logging level, form ID, embed method, cache state, field types, conditional branches, query-string population, and UTC test window. | Repeated display-only requests do not recreate the empty-value sanitized statement. |
| Capture display-only log volume | Load the form without interaction, move between pages, trigger conditional sections, refresh, open a private window, and test both cached and uncached display requests. | Unsafe submitted values are still sanitized or rejected according to the field contract. |
| Exercise real sanitization cases | Submit empty optional fields, empty required fields, spaces, HTML, control characters, multibyte text, arrays, and intentionally malformed values with unique fixture markers. | Required-field validation, stored entries, notifications, and feeds match the written expectations. |
| Update and repeat the matrix | Compare browser payload, validation message, stored value, notification merge tags, add-on feed payloads, and Gravity Forms log output for each fixture. | Log files stay within the retention budget while preserving request, form, field, and result context. |
What to check first
- Record the Gravity Forms version, logging level, form ID, embed method, cache state, field types, conditional branches, query-string population, and UTC test window.
- Load the form without interaction, move between pages, trigger conditional sections, refresh, open a private window, and test both cached and uncached display requests.
- Submit empty optional fields, empty required fields, spaces, HTML, control characters, multibyte text, arrays, and intentionally malformed values with unique fixture markers.
- Compare browser payload, validation message, stored value, notification merge tags, add-on feed payloads, and Gravity Forms log output for each fixture.
- Measure log growth for a fixed request count and confirm rotation, retention, permissions, and monitoring thresholds still protect useful evidence.
Field notes
- Write the pass condition before changing anything. A repeatable synthetic fixture makes the before and after comparison far more useful.
- Keep exact versions and UTC timestamps because scheduled jobs, caches, OAuth refreshes, retries, and background processing can change the evidence.
- Check the public experience and the stored server-side result. Admin previews and isolated API calls do not prove the whole workflow.
- Repeat the test after the relevant cache, queue, scheduled action, webhook, and observation window has finished.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
wp plugin get gravityforms --field=version
wp option get gform_logging_settings
grep -n "value was sanitized" wp-content/uploads/gravity_forms/logs/*.txt | tail -40
# Match every line to a UTC request and synthetic fixture before changing retention.
Why this usually happens
- Display-time field preparation passes an empty value through a sanitizer and logs the operation as if content changed.
- A cached page is blamed even though the duplicate message comes from server-side rendering on every request.
- Broad log search groups harmless empty-value notices with real rejected input from a submission.
- Log rotation removes the exact interval needed to compare behavior before and after the update.
Decision rule
Approve the update when empty display requests stop producing the misleading statement, intentionally unsafe values still receive correct treatment, validation behavior is unchanged, and the remaining logs can be tied to an actual request and field.
Production verification checklist
- Repeated display-only requests do not recreate the empty-value sanitized statement.
- Unsafe submitted values are still sanitized or rejected according to the field contract.
- Required-field validation, stored entries, notifications, and feeds match the written expectations.
- Log files stay within the retention budget while preserving request, form, field, and result context.
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.
- Freeze one marked form fixture
- Capture display-only log volume
- Exercise real sanitization cases
- Update and repeat the matrix
- Retain only useful evidence
Mistakes to avoid
- Changing production before recording plugin versions, WordPress version, PHP version, UTC time, the exact fixture, and a tested rollback point.
- Accepting one successful admin screen while the public form, stored record, API response, accessibility tree, cache, email, or downstream system remains unchecked.
- Testing only as an administrator instead of the role, browser, device, locale, network state, and failure path that a real customer reaches.
- Leaving test accounts, broad credentials, debug logs, temporary compatibility filters, or synthetic customer data active after verification.
Questions teams ask during testing
Should I test this on production?
Use production for read-only evidence first. Reproduce the change on staging with a current data shape, theme, extensions, caching stack, and browser mix. If a production canary is necessary, make it reversible, identifiable, monitored, and unable to charge a customer or expose personal data.
How do I know the result is not a cache artifact?
Record the origin response, purge only the affected paths, and repeat the test in a private session and a normal session. Compare stored data and server logs with the visible page. A cache hit is useful evidence only when you know which version it contains.
What belongs in the evidence packet?
Keep UTC time, exact versions, fixture ID, role, browser, expected result, actual result, relevant response or log lines, change made, rollback point, owner, and final verification. Redact passwords, tokens, personal data, and private URLs.
When can I close the test?
Close it when the primary path and important failure branches pass, records reconcile across systems, accessibility and mobile checks are complete, temporary changes are removed, and monitoring covers the next update or business cycle.
What to tell the client or owner
Give the owner a short packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key evidence, change made, rollback point, unresolved risk, owner, and next review date. Remove 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 diagnose Gravity Forms logs.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Complete the Gravity Forms 3.1.1.1 compatibility review
Custom add-ons should run the Gravity Forms add-on components filter test across page keys, assets, callback priorities, and permissions. File workflows also need the conversational file upload screen reader test so every upload state remains understandable.
Helpful references