Skip to content
Rescue 404
Rescue

Website Forms

WPForms Not Submitting (WordPress Repair)

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

WPForms usually stops submitting when its JavaScript is delayed or broken, a cached form token expires, or a firewall blocks the AJAX request; test once with DevTools open, clear every cache, and temporarily remove script optimization before changing the form itself.

This WordPress Repair guide covers WPForms buttons that do nothing, forms that spin forever, and “unable to submit” or AJAX errors shown before a successful entry. It does not cover a completed entry whose notification email never arrives, because that failure happens after submission. Preserve the working form configuration while you identify whether the browser, cache, or server rejected the request.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • WPForms identifies file-permission problems and ModSecurity rules that block admin-ajax.php as two causes of its AJAX Submit error. (WPForms AJAX Submit error)
  • WPForms uses JavaScript for features including field validation, conditional logic, and CAPTCHA, so a script failure can prevent the complete form workflow. (WPForms JavaScript troubleshooting)
  • WPForms documents that an expired or missing nonce, often associated with page caching, can produce a 403 response. (WPForms 403 troubleshooting)
  • WordPress front-end AJAX requests are sent to wp-admin/admin-ajax.php and identify their handler with an action value. (WordPress AJAX in Plugins)

What the error means

WPForms depends on front-end JavaScript for field validation, conditional logic, CAPTCHA, and optional AJAX submission. The page also carries a security token that proves the request came from the site. A performance tool can reorder the scripts, a page cache can keep the token beyond its useful life, or ModSecurity can reject the POST even while the rest of the page looks normal. The browser Console and Network panels separate those failures: no request points toward JavaScript, while a 403, 500, or malformed response points toward the server. A success response with no email is a separate delivery issue.

Common symptoms

  • Clicking Submit produces no spinner, validation message, or page movement
  • The button remains disabled or displays a loading indicator indefinitely
  • WPForms reports that the page is not loading JavaScript properly
  • The form shows an AJAX submit error or a generic “unable to submit” message
  • Submission works for an administrator but fails for logged-out visitors
  • The Network panel shows admin-ajax.php returning 403, 500, or HTML instead of the expected response
  • Conditional fields, CAPTCHA, or client-side validation also stop responding

Most likely causes

  1. 01 Caching or optimization software deferring, combining, or minifying WPForms scripts incorrectly
  2. 02 A cached form token that is stale when a visitor finally submits the page
  3. 03 ModSecurity, a host firewall, or a security plugin blocking admin-ajax.php or the submitted field content
  4. 04 A plugin or theme JavaScript error stopping WPForms before it binds the submit handler
  5. 05 A custom theme missing the wp_footer() call needed to print required scripts
  6. 06 CAPTCHA keys tied to the wrong hostname or a CAPTCHA script blocked by consent or security rules
  7. 07 Incorrect file permissions preventing WordPress AJAX handling from executing normally

What changed before the problem started

  • A cache, performance, or “delay JavaScript” feature was enabled or reconfigured
  • WPForms, WordPress core, the theme, or another front-end plugin was updated
  • A host firewall, ModSecurity rule, or WordPress security plugin changed
  • CAPTCHA was added, replaced, or issued new keys for a different domain
  • The form moved into a new page-builder template, popup, or custom theme layout

Troubleshooting steps

  1. 01

    Capture one clean failure in a private window

    Open the form logged out, launch DevTools, clear the Console and Network panels, and submit a harmless test. Record the first red JavaScript error and the status and response for admin-ajax.php. Do not repeatedly submit a lead form while the evidence is changing.

  2. 02

    Purge all caches and retest promptly

    Clear the WordPress cache, host cache, CDN cache, and browser cache for the form URL. If a fresh page works, exclude that URL or the form assets from settings that hold HTML or tokens too long instead of scheduling constant manual purges.

  3. 03

    Disable script optimization for the form page

    Temporarily turn off JavaScript delay, defer, combine, and minify features, then reload and test. If submission returns, re-enable optimization one feature at a time and exclude WPForms scripts from the setting that recreates the failure.

  4. 04

    Check the exact AJAX response

    A 403 suggests a firewall, permissions, or expired-token rejection; a 500 suggests PHP failed; no request suggests broken JavaScript. Save the response text because a branded host block page and a WordPress error need different repairs.

  5. 05

    Verify CAPTCHA and visible field behavior

    Confirm CAPTCHA keys belong to the live HTTPS hostname and that its script loads without a blocked-request error. Also test without browser autofill and inspect any conditional required field that may remain hidden while still failing validation.

  6. 06

    Confirm the theme prints WordPress footer assets

    If the form uses a custom theme template, compare it with a standard template and confirm wp_footer() runs before the closing body tag. Do not edit production theme files unless you have a child theme and a restorable copy.

When to stop troubleshooting

Stop DIY testing when this form is the site’s only lead channel and there is no staging copy, firewall events require host access you do not have, PHP errors expose sensitive paths, or conflict testing would disable payment, membership, or security functions. Hand off the form URL, a sanitized export, Console error, AJAX status and response, and the timestamp of one failed test.

Information to collect before requesting help

  • 01 WPForms and WordPress versions, plus whether WPForms Lite or Pro is installed
  • 02 Exact visitor-facing message and whether the button does nothing or spins
  • 03 Console error text and screenshot from a private-window test
  • 04 admin-ajax.php status code and a sanitized response body
  • 05 Cache, optimization, CDN, security, and CAPTCHA products in use
  • 06 Whether the form works while logged in, on staging, or without AJAX enabled
  • 07 Recent plugin, theme, hosting, or domain changes
  • 08 Form URL and a sanitized form export with personal data removed

How a professional repairs the problem

A technician captures the failing request before changing anything, then reproduces it in a controlled copy. They restore the correct WPForms script order, tune cache exclusions and token freshness, trace a rejected POST to its exact firewall rule, repair theme footer loading or plugin conflicts, and validate CAPTCHA on the canonical hostname. The repair ends with logged-out tests across browsers and confirmation that entries are stored; mail delivery is checked separately.

Frequently asked questions

Why does WPForms work when I am logged in? +
Administrators are often excluded from page caching and some firewall checks. Visitors may receive older HTML with a stale token or a differently optimized script bundle, so logged-out testing is essential.
Is an AJAX submit error an email problem? +
No. An AJAX error means the browser did not complete the submission path. SMTP matters only after WPForms accepts the entry and attempts its notification action.
Should I turn off AJAX submission? +
It can be a useful comparison test, but it is not a complete repair. If non-AJAX works, diagnose the blocked or broken AJAX path so features such as conditional behavior remain dependable.
Can caching really make an old form fail later? +
Yes. Cached HTML can preserve a security token or script state longer than intended. Purging may restore the form briefly; proper exclusions prevent the failure from returning.
Will reinstalling WPForms fix the submit button? +
Usually not. Reinstallation does not correct a firewall rule, stale page cache, missing theme footer hook, or another plugin’s JavaScript error.
The entry exists but no email arrived. What next? +
Use the contact-form email delivery guide. A stored entry proves submission worked, so notification settings, SMTP, and domain authentication become the next layer.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.