Neve editor styles are missing in the WordPress 7 editor

[pirate-bot]

Summary

With Neve 4.2.4 in the reported WordPress 7 environment, Neve styling is not applied inside the editor, even with the parent theme active and plugins disabled. The frontend continues to load the theme stylesheet normally.

Expected behavior: the editor preview reflects the site styling so typography, colors, spacing, and layout can be edited visually.

Actual behavior: the editor appears without Neve styling, making visual design work unreliable.

Customer context

Reported from a WordPress.org support thread for Neve 4.2.4. The reporter disabled all plugins, reinstalled Neve, cleared caches, and reproduced the issue with the parent Neve theme, not only a child theme. They report the issue on multiple sites after updating to WordPress 7, while reverting to the previous WordPress version restores the editor styling.

Reproduction notes

Known customer reproduction:

1. Use Neve 4.2.4 on the reported WordPress 7 environment.
2. Disable plugins and activate the parent Neve theme.
3. Open a page in edit mode.
4. Inspect the editor output/source and compare it with the frontend.
5. Observe that Neve styling is missing in the editor while frontend styling still loads.
6. Revert to the prior WordPress version reported by the customer and observe editor styling restored.

Missing from local verification: a runnable WordPress 7 environment and browser-based iframe inspection.

Diagnosis

Conclusion

Neve 4.2.4 has a likely editor-content CSS loading compatibility issue with newer WordPress editor iframe behavior. The inspected code loads Neve editor styling through enqueue_block_editor_assets, while WordPress editor documentation describes that hook as targeting editor UI assets and separates it from content styles expected inside the iframed editor. This aligns with the customer report that the frontend stylesheet still loads, but the editor preview is unstyled.

Where this likely occurs

• inc/core/admin.php:49-64, Neve\Core\Admin::__construct(): registers enqueue_gutenberg_scripts() on enqueue_block_editor_assets, so the editor stylesheet path is tied to the editor asset hook.
• inc/core/admin.php:977-994, Neve\Core\Admin::enqueue_gutenberg_scripts(): after the current-screen guard, enqueues neve-gutenberg-style from assets/css/gutenberg-editor-style(.min).css. Git blame shows this enqueue path is older and not a recent 4.2.4-only change (3c2ab126ce, with path naming adjusted at 102657c548).
• inc/core/dynamic_css.php:28-30, Neve\Core\Dynamic_Css::init(): registers dynamic style generation for the editor only on enqueue_block_editor_assets and for the frontend on wp_enqueue_scripts.
• inc/core/dynamic_css.php:65-85, Neve\Core\Dynamic_Css::enqueue(): generates Gutenberg-specific dynamic CSS and attaches it inline to neve-gutenberg-style; if that handle does not reach the editor content iframe, the generated variables and editor-scoped styles are also absent there.
• inc/core/front_end.php:32-92, Neve\Core\Front_End::setup_theme(): registers many theme supports, but no unconditional editor-styles support was found in the main setup path.
• inc/views/font_manager.php:158-174, Neve\Views\Font_Manager::do_editor_styles_google_fonts(): adds editor-styles support and calls add_editor_style() only when font families are registered; this does not appear to cover the base Neve editor stylesheet path. Git blame points to 70933f82cf.
• inc/core/front_end.php:400-435, Neve\Core\Front_End::add_styles(): registers and enqueues frontend neve-style from style-main-new(.min).css only on the frontend flow. This matches the report that /wp-content/themes/neve/style-main-new.min.css appears for normal visitors but not in edit mode.
• Sibling repo check: neve-pro-addon was searched for style-main-new, editor-styles, add_editor_style(), enqueue_block_editor_assets, and enqueue_block_assets; no Pro override for the base Neve editor stylesheet path was found during inspection.

Engineering notes

• The issue is scoped to editor preview/content styling, not frontend page rendering. The front-end stylesheet path is separate from the editor stylesheet path.
• The reported child theme detail does not appear required for reproduction because the customer reproduced the unstyled editor with the parent Neve theme active.
• WordPress developer documentation states that, for iframed editors, content assets are loaded through editor-content-oriented mechanisms, while enqueue_block_editor_assets is for editor UI assets. Neve’s base editor stylesheet and dynamic CSS currently depend on the editor UI hook path.
• The static source checkout does not include built style-main-new.css or assets/css/gutenberg-editor-style.css; those are generated build outputs. The PHP enqueue paths and SCSS sources were still available for inspection.
• No evidence was found that this is a Neve 4.2.4 regression in the touched files; the relevant enqueue hooks are long-standing. The behavior change is more likely exposed by the reported WordPress version boundary.

Test coverage status

• Relevant e2e coverage exists for typography inside the editor in e2e-tests/specs/customizer/typography/font-family.spec.ts:40-72 and e2e-tests/specs/customizer/typography/font-sizes.spec.ts:93-124; these assert CSS values on .editor-styles-wrapper content.
• No PHP tests covering neve-gutenberg-style, gutenberg-editor-style, enqueue_block_editor_assets, or editor stylesheet registration were found during inspection.
• The existing e2e checks cover typography behavior in the editor, but the inspected tests do not explicitly verify that the base Neve editor stylesheet and dynamic inline CSS are present inside a WordPress 7/editor-iframe document.

What to verify or explore next

• Reproduce on a clean site with Neve 4.2.4 and the reported WordPress 7 build, using the parent theme and no plugins.
• In the post editor or site editor, inspect the editor content iframe document and confirm whether neve-gutenberg-style and its inline dynamic CSS are absent there.
• Compare the same editor iframe inspection on the last known working WordPress version reported by the customer.
• Run the existing editor typography e2e specs against the reported WordPress version boundary, especially e2e-tests/specs/customizer/typography/font-family.spec.ts and e2e-tests/specs/customizer/typography/font-sizes.spec.ts.
• Confirm whether a page with a classic metabox/non-iframed editor path still receives the styles, to distinguish iframe-only behavior from a broader admin enqueue failure.

Unknowns / follow-up

• The exact WordPress 7 build was not available in the workspace, so runtime behavior was inferred from code inspection, customer evidence, and current WordPress editor asset-loading documentation.
• The customer referenced WordPress 6.9.4 as the previous working version; the exact version boundary may need verification against available WordPress release tags or beta builds.

Confidence

Confidence: 82/100

Repo inspection matches the reported missing editor styling: Neve registers editor content CSS through an editor-UI enqueue path, while WordPress editor guidance distinguishes that from styles loaded into iframed editor content. No local WordPress 7 runtime reproduction was available.

---

Source: HelpScout #3338834360
Generated by bug-report-triage workflow (ID: bug-report-triage_6a1ac3462eb556.29666105)

[pirate-bot]

Another customer requested this via support.

Context: The customer wants Arial as the site's uniform font. After configuring all Neve Customizer settings to use Arial, they notice that creating a new post displays text in Georgia instead. They want the editing screen to accurately reflect their site-wide Arial settings.

Source: HelpScout #3354868865

---

Generated by feature-request-triage workflow (ID: feature-request-triage_6a2e5186501af3.48125634)

[pirate-bot]

Another customer requested this via support.

Context: The customer configured Arial as the site-wide font in Neve's Customizer, but when creating a new post, they see the editor fallback to Georgia. They are confused because the backend does not match their configured frontend presentation, making it un-WYSIWYG.

Source: HelpScout #3356816538

---

Generated by feature-request-triage workflow (ID: feature-request-triage_6a30e67644aca3.71398829)

[pirate-bot]

Another customer requested this via support.

Context: A WordPress.org user reported that after setting Arial as the default global font in Customizer, the post editor still displays text in Georgia. They disabled plugins and the issue persisted, indicating that the theme's editor styles are failing to load.

Source: HelpScout #3357991353

---

Generated by feature-request-triage workflow (ID: feature-request-triage_6a31ffb6392121.90070480)

[pirate-bot]

Another customer requested this via support.

Context: The customer wants Arial as the site-wide default font and configured it in the Neve customizer. While it may render properly on the frontend, the backend post editor fails to apply Neve's typography and defaults back to Georgia. This disrupts their editing experience. They have confirmed this occurs even with all plugins disabled.

Source: HelpScout #3359027273

---

Generated by feature-request-triage workflow (ID: feature-request-triage_6a32fcd7a75af7.49516349)

[HardeepAsrani]

@rodica-andronache I can't reproduce this issue. If I inspect the style on both pre-7.0 and 7.0, the same stylesheet is loading. Are you able to reproduce this issue?

[rodica-andronache]

@HardeepAsrani I can't reproduce it either. Maybe it was actually this issue which got fixed #4518