A Gravity Forms submission that ends in a PHP fatal error needs a server-side investigation, not a weaker spam filter. If the stack trace mentions wp_kses_allowed_html, inspect custom sanitization callbacks. Gravity Forms currently lists a related fix under 3.1.3.1, but that entry does not prove every submission crash has this cause.
Confirm the failure before changing the form
Record the form ID, installed Gravity Forms version, PHP version, request time and whether an entry was created. Use a synthetic submission on staging. A failed browser confirmation can occur after an entry was saved, so repeatedly clicking Submit can create another problem.
Read the private PHP error log for the matching request. Preserve the exception type and relevant function names without copying submitted names, emails or message bodies into a public ticket. If there is no fatal error, investigate the actual response instead of applying this diagnosis by keyword alone.
The official changelog describes a fatal error during field-value sanitization when another component incorrectly uses the filter. It lists 3.1.3.1 without a release date. Confirm package availability through your licensed installation; do not download a similarly named ZIP from an unofficial source.
Find the callback owner
On a development copy, search the child theme, custom plugins and must-use plugins for the filter name. This read-only command searches application code, not the database:
rg -n 'wp_kses_allowed_html' wp-content/themes wp-content/plugins wp-content/mu-plugins
Adjust paths that do not exist. Also inspect the code-snippet manager if the site stores custom callbacks there. A matching filename identifies a candidate, not proof of fault. Ask the developer to trace which callback actually executes for the failing request.
WordPress documents the filter contract: the allowed-HTML value is an array and the context is a separate argument. Review return values on every branch, including contexts the customization was not designed to handle. An unconditional replacement, missing return or unexpected value type deserves attention.
Reproduce: Same synthetic submission. Identify: Actual callback in stack. Compare: Patch and customization separately. Accept: One entry and correct validation. Explanatory checklist, not a customer test result.
Compare the patch and customization separately
Use the same synthetic form data in a small staging experiment. First reproduce with the current theme and plugin set. Then test the vendor-supported update. If the error remains, isolate the identified customization on that copy and rerun the request. Change one variable at a time so the result identifies a repair owner.
Do not remove all sanitization, allow arbitrary HTML globally or disable security controls to make the confirmation appear. Those changes can turn a visible failure into unsafe stored content. Keep a known working deployment available while correcting the callback.
Check more than the confirmation screen
Verify one entry, expected stored field values, required-field validation and the intended notification or feed. Test ordinary text, an empty optional field and the form's legitimately supported formatting. Compare values with the documented form policy rather than assuming all markup should survive.
If your evidence is only an empty-value log message on page display, use the sanitized-log diagnosis. For a reproducible crash, HandL WP can trace the PHP callback using the redacted stack and test case.
References reviewed October 10, 2026. Examples are explanatory, not customer test results.