Troubleshooting W3 Total Cache Issues with Gravity Forms

Overview

This article explains how W3 Total Cache’s caching and minification features can interfere with Gravity Forms, and how to identify and resolve the conflict.

W3 Total Cache combines several caches into a single plugin: page, minify, database, object, and browser. Any of them can affect a form, so the first step is to determine which one is active on the page.

Symptoms

  • Conditional logic or other JavaScript-driven features don’t respond.
  • Fields display incorrectly.
  • Forms fail to submit or show submission errors.
  • Blank screens appear after submission.
  • Form data doesn’t process correctly.
  • Save and Continue behaves unexpectedly.
  • Conversational Forms or other add-on functionality breaks.
  • Forms work differently for logged-in users than for cached public visitors.

Why It Happens

Minify

It can combine Gravity Forms’ scripts with other files and move them elsewhere in the page. Gravity Forms scripts are already minified, and combining them changes both their order and the point at which they run. If this stops the honeypot’s script from running correctly, the submission’s version hash and timing data are missing, and Gravity Forms flags the entry as spam.

Performance › Minify

Note: When Minify causes this, the submission isn’t lost. The visitor still sees a confirmation, but the entry is saved under Forms › Entries › Spam rather than the main list, and its notes identify the honeypot filter that flagged it. Check there before assuming a submission never arrived.

Page Cache

It stores the rendered HTML and serves that copy to later visitors. A nonce from that render is reused until the cache is purged, so Ajax submissions and forms that require the visitor to be logged in fail once the session has expired.

Performance › Page Cache

Object Cache and Database Cache

These store the results of database queries. Form definitions, field settings, and entry data all come from the database, so a stale cache can serve an old version of a form or interfere with reading back what was just saved. W3 Total Cache’s default database exclusion is the old wp_rg_ tables. Current Gravity Forms tables use gf_, so Database Cache doesn’t skip them unless wp_gf_ is added to Ignored query stems.

Performance › General Settings

Confirm the Issue

  1. Open the form page in a private window, right-click, and select View Page Source.
  2. Scroll to the very bottom and look for a comment that begins with “Performance optimized by W3 Total Cache.”
  3. Read what that comment lists. It names the features that ran, for example, “Page Caching using Disk: Enhanced.” “(User is logged in)” means that the feature didn’t serve you a cached copy. Test the features it lists first.
  4. If no comment appears, HTML minify may have removed it. Treat Minify as the next thing to test, and don’t assume the page is uncached.
  5. If submissions seem to be going missing, open Forms › Entries and switch to the Spam view. Open an entry there and read its notes. They name the filter that flagged it.

How to Fix It

  1. Go to Performance › Dashboard and click Empty All Caches, then retest the form in a private window.
  2. If entries are landing in Spam, or conditional logic is broken, go to Performance › Minify and add the Gravity Forms scripts to Never Minify the Following JS Files. To confirm that Minify is the cause before tuning it, disable Minify entirely at Performance › General Settings and submit a test entry.
  3. Add your form pages to Never Cache the Following Pages at Performance › Page Cache › Advanced. This field takes regular expressions rather than plain URLs, so escape any special characters in the path.
  4. If the form still behaves inconsistently, disable Object Cache and Database Cache at Performance › General Settings, purge, and retest.
  5. Re-enable one at a time, purging and retesting after each, so you finish knowing which cache was responsible rather than leaving them all off.

Resources