Initial assessment without passwords Quote before intervention One accountable specialist from start to finish

Locate Message Failure

A WordPress Form Spins Forever After the Visitor Clicks Submit

Diagnose a WordPress form stuck on the loading spinner through JavaScript errors, AJAX/REST responses, security rules, PHP and email timing.

A permanent spinner means the front end never reached its expected completion state. The request may not have left the browser, may be blocked by Cloudflare/security, may fail in PHP or may wait on a slow external mail/CAPTCHA service.

Do not keep clicking Submit. Duplicate requests can create multiple leads even while the interface remains stuck.

Reproduce once with a unique reference

Use a private logged-out session, a harmless unique test value and browser developer tools open before submission.

Record page URL, time, browser, consent/CAPTCHA state and whether refreshing reveals a saved entry.

Test mobile and desktop only after one path is understood.

Check the browser console

Look for JavaScript exceptions before and after clicking. Record the first error, source file and stack rather than a later cascade.

Common owners include optimisation/minification, form plugin, theme, consent, CAPTCHA and third-party scripts.

Temporarily disable one suspected optimisation in staging. Do not exclude all JavaScript globally on production.

Inspect the submission request

In the network panel, find the POST/AJAX/REST request. Possible outcomes:

  • no request: click handler or validation failed;
  • pending: network/server/external work is waiting;
  • 403: nonce/WAF/CAPTCHA/security rejection;
  • 404: wrong endpoint/domain/permalink;
  • 500: PHP fatal/server error;
  • 200 with invalid body: cache/proxy/plugin response mismatch.

Save status and response excerpt without exposing form data or tokens.

Correlate server and WordPress logs

Match the request timestamp/request ID with web/PHP logs and form entries. A 500 stack can identify the plugin callback or memory/timeout.

Enable diagnostics without displaying errors publicly. Avoid logging full names, emails, messages and uploaded files.

If an entry exists, the server processed at least part of the request; check where the response stopped.

Test email as a blocking dependency

Some form plugins send email synchronously before returning success. A slow SMTP connection, DNS lookup or provider timeout can keep the browser spinning.

Review mail logs and compare a staging submission with notifications disabled while still storing the entry. If the response becomes immediate, repair SMTP/notification timing.

Do not leave notifications disabled on production without an alternate lead workflow.

Check security and CDN layers

Cloudflare challenges, ModSecurity/WAF and rate limits can block POST bodies, AJAX endpoints or file uploads. Review exact rule/event IDs with the provider.

Allow the narrow verified endpoint/rule pattern, not the whole site or every POST request.

Purge cache only if a stale script/nonce is confirmed. Forms/endpoints should not be cached as static responses.

Verify UI and lead outcome

After the repair, submit once without scrolling or extra interaction. Confirm spinner stops, accessible success/error message appears, entry saves once and email/provider/mailbox receives one notification.

Test validation errors, consent, CAPTCHA, attachment and mobile keyboard. Confirm analytics records success only after server confirmation.

Prevent duplicate and abandoned leads

A visitor who sees an endless spinner often clicks again, refreshes or leaves. Check whether each click created another entry before resubmitting tests. The submit button may be disabled while a request is active, but it must become usable again after a genuine error.

Do not solve the symptom with a fixed timer that hides the spinner and displays success. The interface must use the actual server response. On failure, preserve safe field values where possible and show a useful retry message without exposing PHP paths, database details or security rules.

If enquiries are commercially urgent, publish a monitored fallback contact route until the request path is stable.

When to request form repair

Request urgent help when the spinner creates duplicate/unknown leads, endpoints return 403/500 or SMTP blocks the response. Send URL, timestamp, request status and console error with personal data removed.

The repair should fix both the request and the truthful user feedback—not merely hide the spinner.

BEFORE YOU SEND THE REQUEST

Frequently asked questions.

Do you ask for passwords in the form?+

No. The public form never requests access. Secure credentials are requested only after the scope and quote are approved.

Who reviews the incident?+

The request goes to Jordi Ensenyat, founder of Code Barcelona and a WordPress specialist with more than 15 years of experience.

Is anything changed before the quote?+

No. Visible symptoms and scope are reviewed first. Intervention begins after approval and with a rollback path prepared.

Do you work internationally?+

Yes. WP Repair handles WordPress and WooCommerce incidents in English and Spanish through a remote service.

Assess my incident