Gravity Forms 2.10.5 fixes WordPress 7 Custom CSS block settings not working on the first form embedded in a page. Block order, reusable patterns, templates, query loops, lazy rendering, optimization, and page cache can make the first rendered instance differ from the first block in the editor.
Use this for WordPress 7 sites with multiple Gravity Forms blocks, patterns, popups, template parts, conditional embeds, or per-block Custom CSS settings.
Quick answer
Create a page with three forms and distinct harmless Custom CSS markers, then change block order and render through the theme, patterns, cache, and mobile breakpoints. Update to 2.10.5, purge generated assets, and compare computed styles plus selectors for each instance. Pass only when the first rendered form receives its own settings without leaking styles into later forms.
What to check first
- Record WordPress, Gravity Forms, theme, block API, cache, optimizer, page builder, form IDs, block order, DOM order, wrapper IDs, CSS settings, and generated asset URLs.
- Test one form, three forms, repeated form ID, reusable pattern, synced pattern, template part, query loop, popup, hidden tab, and server-rendered block.
- Give each fixture a visible but harmless border, spacing, label, button, focus, validation, and responsive marker scoped to the intended wrapper.
- Compare editor preview, logged-in frontend, anonymous cache, prerendered HTML, computed styles, generated CSS, mobile, RTL, validation failure, and AJAX confirmation.
- Move the first block, duplicate it, clear Custom CSS, switch themes, purge caches, and repeat to identify stale asset or selector ownership.
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 |
|---|
| Build distinct CSS markers | Record WordPress, Gravity Forms, theme, block API, cache, optimizer, page builder, form IDs, block order, DOM order, wrapper IDs, CSS settings, and generated asset URLs. | The first DOM form matches its configured Custom CSS after anonymous cache load. |
| Capture editor and DOM order | Test one form, three forms, repeated form ID, reusable pattern, synced pattern, template part, query loop, popup, hidden tab, and server-rendered block. | Later forms do not inherit the first form's scoped marker. |
| Update and purge generated assets | Give each fixture a visible but harmless border, spacing, label, button, focus, validation, and responsive marker scoped to the intended wrapper. | Reordering or duplicating blocks updates the generated output predictably. |
| Compare scoped computed styles | Compare editor preview, logged-in frontend, anonymous cache, prerendered HTML, computed styles, generated CSS, mobile, RTL, validation failure, and AJAX confirmation. | Validation, focus, confirmation, mobile, and RTL states retain intended styles. |
Why this usually happens
- The first instance can initialize shared style state before its own settings are read.
- Repeated block IDs or selectors can attach styles to the wrong wrapper.
- Cached generated CSS can outlive a block-order change.
- Hidden or lazy content can become the first rendered form after page load.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
forms: [7, 12, 19]
first_dom_form: 7
custom_marker: 3px solid rgb(1, 120, 210)
computed_border_form_7: match
form_12_leak: false
anonymous_cache: pass
mobile: pass
validation_state: pass
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.
- Build distinct CSS markers
- Capture editor and DOM order
- Update and purge generated assets
- Compare scoped computed styles
- Retest ordering and lazy embeds
Decision rule
Pass when every form receives only its configured block styles across order, cache, validation, AJAX, breakpoints, and lazy rendering, with no selector leak into another instance.
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
- The first DOM form matches its configured Custom CSS after anonymous cache load.
- Later forms do not inherit the first form's scoped marker.
- Reordering or duplicating blocks updates the generated output predictably.
- Validation, focus, confirmation, mobile, and RTL states retain intended styles.
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
Can the editor preview prove the fix?
No. Test anonymous frontend output, generated CSS, cache, computed styles, validation, and responsive states.
Should Custom CSS use global selectors?
Prefer scoping to the form wrapper or supported block context so one embed cannot style unrelated forms.
When HandL WP should help
Bring in HandL WP when a production checkout, form, editor, security gate, media pipeline, 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 block styles.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references