WordPress Form Troubleshooting — WP Forms vs Gravity Forms

Overview

When a WordPress site's contact form stops working, the fix often surfaces a broader question: which form plugin should we be using, and does it still make sense given the client's CRM stack? This article captures the decision framework for choosing between WP Forms and Gravity Forms, notes on integration patterns, and when to defer to a CRM platform's native forms instead.

Choosing a Form Plugin

Default Recommendation: Gravity Forms

On new WordPress builds, the default is Gravity Forms. Key reasons:

• Included in the agency's toolset — no additional per-client cost
• Preferred by internal developers (Eshak, Jeff) for reliability and extensibility
• Handles complex field types, conditional logic, and multi-step forms cleanly
• Easier to debug when things break

WP Forms is not a bad choice, but it tends to appear on sites we inherit rather than sites we build. If a client is already running WP Forms and it's working, there's no strong reason to migrate unless issues arise.

When to Reconsider Either

If the client is adopting a CRM platform that includes its own native forms, evaluate whether to use those instead:

• Go High Level — Chris's preference; GHL forms integrate tightly with GHL pipelines and automations
• HubSpot — native forms work well when the client is fully in the HubSpot ecosystem
• Jane App — healthcare/wellness CRM with built-in forms, questionnaires, consents, and insurance fields; if a client adopts Jane, their intake forms should likely live there rather than on WordPress

Rule of thumb: Forms should live where the data needs to go. If the CRM has capable native forms and the client is committed to that platform, use them. If the client has no CRM or a lightweight one, keep forms on WordPress with Gravity Forms.

Troubleshooting a Broken Contact Form

When a client reports that their contact form isn't working:

1. Confirm the symptom — Is the form not submitting? Not sending email notifications? Silently failing? The fix differs significantly.
2. Check the form plugin — Log into WordPress and verify the form is active and configured correctly.
3. Check email delivery — Form submissions often fail at the email notification step, not the submission itself. Look for SMTP configuration issues or a missing/misconfigured mail plugin.
4. Check hosting environment — Some hosts block outbound mail from PHP by default. This is a common culprit on shared or managed hosting.
5. Assign to a developer — For Asymmetric clients, route to Eshak or Jeff first; Akeek can also investigate. Eshak is preferred when a live call or screen share may be needed.

Target resolution time: Same-day task assignment; fix within 2–3 business days for active client sites.

CRM Integration Considerations

When a client introduces a new CRM, audit all existing forms for compatibility:

• Will form submissions need to route to the new CRM?
• Does the CRM offer a native form embed or webhook?
• Are there existing Zapier/automation connections that will break?

If the client is still evaluating CRM platforms, hold off on rebuilding forms until the decision is made. Fix any immediate breakage with the existing setup, but don't invest in a new integration until the CRM is confirmed.

Example: Shine Marketing (A New Dawn) was experiencing WP Forms issues while simultaneously evaluating Jane App as a CRM. The decision was made to fix the existing WordPress form immediately, then reassess form strategy once the Jane adoption decision was finalized. See ^[1] and ^[2].

Developer Routing Guide

Related

• ^[3]
• ^[4]
• ^[5]
• ^[1]