Saving a page containing a completely ordinary contact-style form returned a save error with no valid response – nothing in any accessible log explained why.
A URL-Shaped Field Name Can Get a Legitimate Form Rejected on Save
Field Note #266
⚡ Quick Fix (TL;DR)
The Culprit: An with an id referencing "url" and a placeholder that looked like a website address was enough to trigger the rejection. The exact same markup, already saved elsewhere on the site, worked fine – only a fresh save of that content failed.
The Fix: Bisecting the markup itself, one attribute at a time, isolated it to the specific combination of a URL-referencing id plus a URL-shaped placeholder value – a naming pattern that a hosting provider's own server-level security layer was reacting to before the request ever reached WordPress. Renaming the id and softening the placeholder text, with no other change, resolved it immediately. Hosting-level security software can reject a save based on field naming, not just field type or actual content.
Was this helpful? Thanks for the feedback!
Tagged in :
More from the field
Bisect to an Empty Baseline Before Trusting Any Single Theory
.
Multiple plausible-sounding theories for a bug each turned out to be wrong when actually tested – time was spent building fixes…
A Security Dashboard’s Activity Log Can Lag a Full Day Behind Real Time
.
Trying to check a security tool’s activity log for an event that had just happened showed nothing at all.