Gravity Forms Conditional Logic Not Working: Why Your Forms Are Broken After Update

Conditional logic breaks silently and stays broken

Gravity Forms is one of the most widely used form plugins for WordPress, powering everything from simple contact forms to complex multi-page application forms with dozens of conditional rules, calculations, and payment integrations. Conditional logic is its most powerful feature — and its most fragile.

Conditional logic runs entirely in the browser using JavaScript. When a user selects an option, JavaScript evaluates the rules you defined in the form builder and shows, hides, enables, or disables fields in real time. When that JavaScript breaks, conditional logic stops working. But the form itself still appears on the page. The server still returns 200. Your uptime monitor still reports the page as healthy. The form just malfunctions — silently, invisibly, for every visitor.

The worst scenario is a form where conditional logic controls required fields. A visitor fills out a form where the "Company size" field should only appear when they select "Business" account type. The conditional logic is broken, so the field never appears. But the field is marked as required. The visitor clicks Submit and gets a validation error for a field they cannot see. They try again. Same error. They leave. You never know it happened because no form entry was created.

What causes Gravity Forms conditional logic to break

1. jQuery conflicts with other plugins

Gravity Forms depends heavily on jQuery for its frontend functionality. Conditional logic, field calculations, multi-page navigation, and dynamic field population all use jQuery. When another plugin loads a different version of jQuery, removes jQuery, or modifies the jQuery loading order, Gravity Forms' JavaScript can break.

The most common conflict is a plugin or theme that loads jQuery from a CDN instead of using the WordPress-bundled version. WordPress loads jQuery in noConflict mode. The CDN version might not. Gravity Forms expects noConflict mode. When it is not available, the gform.initializeOnLoaded function fails silently, and no conditional logic rules are attached to the form fields.

Another common conflict is a plugin that dequeues WordPress's jQuery and replaces it with a newer or older version. Gravity Forms is tested against the jQuery version that ships with WordPress. A different version can have subtle API differences that cause the conditional logic evaluation to fail — returning undefined where it expects a boolean, or triggering events in a different order.

2. JavaScript minification and combination

Performance plugins that minify and combine JavaScript files are one of the top causes of Gravity Forms breakage. Gravity Forms loads several JavaScript files that depend on each other in a specific order: the core form scripts, the conditional logic engine, the calculation engine, the multi-page handler, and the payment scripts.

When a performance plugin combines these into a single file, the loading order can change. When it minifies them, variable names can collide. A semicolon that was technically optional in a standalone file becomes critical when two files are concatenated. The result is a JavaScript error that breaks the entire conditional logic system.

This is particularly insidious because the breakage might not appear immediately. The performance plugin caches the combined file. Your browser caches it. You test the form and it works because you are seeing the pre-combination cached version. Days later, the cache expires, the browser downloads the new combined file, and conditional logic stops working. By the time you notice, you have forgotten that you changed your performance plugin settings a week ago.

3. PHP 8.x compatibility issues

PHP 8.0, 8.1, and 8.2 introduced strict type checking and removed several deprecated functions. Gravity Forms core has been updated for PHP 8.x compatibility, but many add-ons have not. A Gravity Forms add-on that worked fine on PHP 7.4 can throw fatal errors on PHP 8.1 — and those errors can be partial, crashing only specific form functionality rather than the entire page.

Common PHP 8.x issues with Gravity Forms add-ons include: strlen() no longer accepting null values (PHP 8.1), str_replace() requiring string arguments instead of accepting null, deprecated create_function() calls in older add-ons, and named parameter conflicts. These errors can crash the form rendering process partway through, producing a form that loads but is missing fields, validation rules, or the conditional logic JavaScript.

If your hosting provider recently upgraded PHP from 7.4 to 8.x — which many are doing now that PHP 7.4 is end of life — Gravity Forms add-ons that have not been updated for PHP 8 compatibility will break. The form might still render, but the fields controlled by the broken add-on will malfunction.

4. Payment integration failures

Gravity Forms integrates with Stripe, PayPal, and other payment processors through add-ons. These add-ons inject additional JavaScript into the form to handle payment field rendering, tokenisation, and submission. When a payment add-on's JavaScript fails, it can break the entire form — not just the payment fields.

The Stripe add-on, for example, loads Stripe.js and attaches it to the form submission process. If the Stripe add-on encounters an error — an invalid API key, a JavaScript conflict with another plugin, or a Stripe.js version mismatch — the form submission handler breaks. The visitor fills out the form, clicks Submit, and nothing happens. No payment is processed. No form entry is created. The form just sits there.

PayPal integrations have their own set of issues. The PayPal Commerce Platform add-on loads PayPal's JavaScript SDK, which can conflict with other scripts that also load the PayPal SDK (WooCommerce PayPal, for example). Two PayPal SDK instances on the same page cause unpredictable errors.

5. Theme or page builder conflicts

Page builders like Elementor, Divi, and WPBakery load their own JavaScript frameworks. These frameworks can interfere with Gravity Forms' JavaScript, especially when forms are embedded inside page builder widgets or modules. Elementor's frontend JavaScript, for example, initialises widgets after the DOM is loaded. If Gravity Forms initialises its conditional logic before Elementor finishes building the DOM, the form fields that Gravity Forms targets might not exist yet.

Themes that include built-in form styling can also cause problems. A theme that applies CSS transforms or display:none to form elements during page load can interfere with Gravity Forms' conditional logic visibility checks. Gravity Forms hides fields by setting display: none via JavaScript. If the theme also sets display: none and then removes it on a different timing, the two compete and fields show or hide at the wrong times.

How to diagnose broken Gravity Forms

Check the browser console first

Open the page with your Gravity Form. Press F12 to open developer tools. Click the Console tab. Reload the page. Look for red errors. Any JavaScript error on the page — even from an unrelated plugin — can cascade and break Gravity Forms' conditional logic. The error message tells you which file and line number caused the problem. If the error is in a file that is not part of Gravity Forms, that plugin is the one breaking your form.

Test with all other plugins deactivated

Deactivate every plugin except Gravity Forms. Test your form. If conditional logic works, the problem is a conflict with another plugin. Reactivate plugins one at a time, testing the form after each one. When conditional logic breaks, you have found the conflicting plugin.

Disable JavaScript minification and combination

If you use WP Rocket, Autoptimize, LiteSpeed Cache, or any other performance plugin that minifies or combines JavaScript, disable those features temporarily. Test your form. If conditional logic works without minification, the performance plugin is breaking it. Exclude Gravity Forms JavaScript files from minification and combination. In WP Rocket, go to File Optimization and add the Gravity Forms script URLs to the excluded JavaScript files list.

Check PHP error logs

Enable WP_DEBUG_LOG in wp-config.php and check /wp-content/debug.log for errors. PHP errors in Gravity Forms add-ons can prevent conditional logic rules from being output to the page. The form renders but the JavaScript that defines the conditional rules is missing from the page source. Check for deprecation notices and fatal errors from any file in the gravityforms directory.

How to fix each type of Gravity Forms failure

jQuery conflict fix

Identify which plugin is loading a conflicting jQuery version using the browser Network tab — filter by "jquery" and look for multiple jQuery files loading. Deactivate the conflicting plugin or configure it to use the WordPress-bundled jQuery. If a theme is the culprit, contact the theme developer — loading a custom jQuery is a well-known bad practice that breaks many plugins.

Minification fix

In your performance plugin, exclude Gravity Forms JavaScript files from minification and combination. The files to exclude typically include any URL containing /gravityforms/ or gform. Test the form after excluding. If it works, you have solved the problem without sacrificing overall performance — only the Gravity Forms scripts are excluded, everything else remains optimised.

PHP 8 fix

Update Gravity Forms and all add-ons to their latest versions. If an add-on does not support PHP 8, check the Gravity Forms add-on page for an updated version or an alternative. Do not downgrade PHP to fix the issue — PHP 7.4 is end of life and no longer receives security updates. Fix the compatibility at the plugin level.

Payment integration fix

Check your payment gateway API keys. Test in Stripe's or PayPal's sandbox mode. Check the browser console for JavaScript errors from the payment SDK. Ensure only one instance of the payment SDK loads on the page. Update the payment add-on to its latest version. If the problem persists, disable other plugins that load the same payment SDK.

How to monitor Gravity Forms with Uptrue

Uptrue's keyword monitoring checks that your form pages contain the expected content. If a PHP error, JavaScript failure, or plugin conflict prevents your Gravity Form from rendering, Uptrue detects the missing content and alerts you immediately.

Step 1: Set up a keyword monitor on your form page

1. Sign up at uptrue.io/signup (free plan available)
2. Click Add Monitor from your dashboard
3. Select Keyword as the monitor type
4. Enter the URL of the page containing your Gravity Form
5. Set the keyword to your form's submit button text — typically "Submit" or whatever custom text you configured
6. Set the check type to "Page must contain"
7. Set the check interval to 1 minute
8. Configure alerts — Slack, email, or Microsoft Teams

If a PHP fatal error crashes the form rendering, the submit button text disappears from the page. If a JavaScript error prevents the form from initialising and the form is rendered via JavaScript (AJAX-enabled forms), the form content may be missing. Uptrue detects the missing keyword and alerts you.

Step 2: Monitor for error text on the form page

1. Click Add Monitor again
2. Select Keyword as the monitor type
3. Enter the same form page URL
4. Set the keyword to "fatal error"
5. Set the check type to "Page must NOT contain"
6. Set the interval to 1 minute

This catches PHP fatal errors that display on the page instead of the form. If WordPress debug display is accidentally enabled, or if the error occurs before output buffering starts, the error message appears on the page. Uptrue catches it immediately.

Step 3: Add an HTTP monitor for server-level failures

1. Add an HTTP/HTTPS monitor for the form page URL
2. Set expected status to 200
3. Set check interval to 1 minute

This catches complete page crashes — 500 errors from PHP fatal errors that kill the entire page, not just the form. Between the keyword monitors and the HTTP monitor, you cover form-level failures, page-level error messages, and server-level crashes.

Step 4: Monitor every page with a critical form

If you use Gravity Forms on multiple pages, set up monitors for each one:

• Contact page — check for the submit button text
• Quote request page — check for form-specific text like "Request a quote"
• Application forms — check for "Submit application"
• Payment forms — check for "Pay now" or "Complete purchase"
• Registration forms — check for "Register" or "Create account"

Step 5: Set up alerts that reach you fast

• Slack — instant notification when form content disappears
• Microsoft Teams — visibility for the development team
• Email — written record of every form failure incident
• Webhook — trigger automated incident response

Preventing Gravity Forms breakage

Test forms after every update

After every Gravity Forms update, WordPress core update, PHP version change, or plugin update, test your forms manually. Open the page. Fill out the form. Test every conditional logic path — select different options and verify that the correct fields show and hide. Submit the form and verify the entry is created correctly. This takes five minutes and prevents days of lost form submissions.

Use a staging environment

Always update on staging first. Test all forms. Only push to production when everything works. Most managed WordPress hosts offer one-click staging that copies your entire site including Gravity Forms entries and settings.

Exclude Gravity Forms from script optimisation

In your performance plugin, add Gravity Forms scripts to the exclusion list. The small performance cost of unminified Gravity Forms JavaScript is negligible compared to the cost of broken forms losing submissions for days.

Keep add-ons up to date

Gravity Forms core and its add-ons are maintained by different teams on different release schedules. When you update Gravity Forms core, check that all your add-ons have compatible versions. An outdated add-on running against a new core version is one of the most common causes of form breakage.

Your forms are probably losing submissions right now

That is not an exaggeration. Gravity Forms conditional logic depends on a fragile chain of JavaScript execution. A jQuery conflict from an unrelated plugin. A minification setting you forgot about. A PHP 8 upgrade your host applied. A Stripe API key that expired. Any one of these can silently break your forms while the page continues to load normally and your uptime monitor reports everything as healthy.

Visitors fill out your form, click Submit, and nothing happens. They do not call you to report it. They do not email you. They go to your competitor. You check your form submissions at the end of the week and wonder why leads are down. You blame the marketing. You blame the season. You do not check the browser console.

Uptrue keyword monitoring checks your form pages every 60 seconds. If the form disappears, if an error message appears, if the submit button text is missing — you know in under a minute. Before the next lead fills out a form that does not work. Before another day of lost submissions.

Frequently asked questions