Gravity Forms 2.10.5 fixes a JavaScript problem where `gravityforms.js` could reset `gform.instances` when scripts were optimized, causing errors while forms display or submit. Old page cache, combined bundles, and CDN assets can keep the broken sequence after the plugin update.
Use this when Gravity Forms fail after deferring, delaying, combining, minifying, or moving JavaScript, especially on pages with several forms, AJAX, conditional logic, payment fields, or popup rendering.
Quick answer
Record the current Gravity Forms and asset versions, preserve the console stack and script order, then update to 2.10.5 or later on staging. Purge generated optimizer bundles and CDN cache, confirm `gform.instances` survives every script execution, and retest display, validation, AJAX, popup, history, and submission. Keep exclusions narrow and version-specific.
What to check first
- Capture Gravity Forms version, WordPress version, optimizer version, cache plugin, CDN, script handles, generated bundle URLs, load order, attributes, and console stack.
- Inspect `window.gform`, `gform.instances`, object identity, registered form IDs, and event timing before and after each Gravity Forms script runs.
- Test one form, several forms, footer form, popup form, AJAX, multipage, conditional logic, validation failure, browser back, and a successful submission.
- Update to 2.10.5 or later, rebuild optimized assets, purge page and CDN cache, and compare the same sequence before changing exclusions.
- If failure remains, disable delay, defer, combine, and minify separately to name the first transformation that changes registry behavior.
Diagnostic table
Use this table to keep the work practical. It connects the symptom to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Preserve the failing script trace | Capture Gravity Forms version, WordPress version, optimizer version, cache plugin, CDN, script handles, generated bundle URLs, load order, attributes, and console stack. | All page and CDN requests return the current Gravity Forms asset build. |
| Update Gravity Forms on staging | Inspect `window.gform`, `gform.instances`, object identity, registered form IDs, and event timing before and after each Gravity Forms script runs. | `gform.instances` is not replaced after forms register. |
| Rebuild and purge optimized assets | Test one form, several forms, footer form, popup form, AJAX, multipage, conditional logic, validation failure, browser back, and a successful submission. | Display, validation, AJAX, popup, history, and submission complete without console errors. |
| Verify registry identity and form flows | Update to 2.10.5 or later, rebuild optimized assets, purge page and CDN cache, and compare the same sequence before changing exclusions. | Optimization remains enabled except for the narrow transformation proven incompatible. |
Why this usually happens
- Optimizers can execute dependencies in a different order than WordPress enqueued them.
- A combined file can retain older Gravity Forms code after the plugin changes.
- Two script copies can initialize the same global at different times.
- Popup and AJAX rendering expose lifecycle paths absent from a simple page load.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
console.log({
gfVersion: '2.10.5',
registry: window.gform?.instances,
formIds: Object.keys(window.gform?.instances || {}),
readyState: document.readyState,
scripts: [...document.scripts].filter(s => /gravityforms|gform/.test(s.src)).map(s => s.src)
});
Safe fix order
Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.
- Preserve the failing script trace
- Update Gravity Forms on staging
- Rebuild and purge optimized assets
- Verify registry identity and form flows
- Keep only proven script exclusions
Decision rule
Pass when the registry remains available and retains every active form across the complete optimized lifecycle, submissions finish once, and no stale bundle or duplicate script remains.
What to tell the client or owner
Give the owner the affected versions, exact workflow, observed result, business impact, evidence location, temporary control, named owner, and next review time. Remove credentials and personal data from shared screenshots and logs.
Production verification checklist
- All page and CDN requests return the current Gravity Forms asset build.
- `gform.instances` is not replaced after forms register.
- Display, validation, AJAX, popup, history, and submission complete without console errors.
- Optimization remains enabled except for the narrow transformation proven incompatible.
Mistakes to avoid
- Do not change several plugins, cache rules, or infrastructure settings before preserving a baseline.
- Do not treat one successful test as proof for retries, alternate clients, background work, or mixed-version fleets.
- Do not paste secrets, personal data, complete production payloads, or customer files into tickets or screenshots.
- Do not close the test until the final user-visible state and the server-side evidence agree.
Questions teams ask during testing
Is purging the page cache enough after updating?
Not always. Optimizers and CDNs can store generated JavaScript under separate keys. Verify the actual script URL and bytes returned to anonymous users.
Should every Gravity Forms script be excluded?
No. Broad exclusions can hurt performance and hide ordering mistakes. Exclude only the handle or transformation proven by the trace.
When HandL WP should help
Bring in HandL WP when a production checkout, form, email, media pipeline, code-quality gate, or paid lead workflow is at risk. We can preserve evidence, isolate the failing layer, make the smallest corrective change, and verify the result across WordPress, connected services, logs, and the user journey.
If this is active on a production site, fix Gravity Forms JavaScript errors.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Verify the first embedded form receives its block CSS
The same current release also fixes Custom CSS on the first embedded form in WordPress 7. Use the Gravity Forms 2.10.5 first-form Custom CSS test across block order, patterns, cache, validation, and responsive states.
Test delayed containers and several form instances
Extend the script fix with the Gravity Forms 2.10.5 popup lazy-render optimizer test and the multiple-form registry identity test for popups, repeated embeds, handler counts, AJAX replacements, and cross-form state.
Helpful references