Skip to content

Post editor canvas can become blank when Neve content width resolves to 0px #4504

Description

@pirate-bot

Summary

Opening or creating posts can show existing blocks briefly and then leave the editor canvas blank after editor styles load. The blocks remain present in List View, but they are not visible or editable on the canvas.

Expected behavior: post blocks remain visible in the editor canvas after Neve editor styles finish loading.

Actual behavior: for affected post width settings, the editable block area can collapse so the canvas appears empty. Pages can remain unaffected because they use a separate content-width setting.

Impact: affected users may be unable to edit or create posts in the block editor even though the post content still exists.

Customer context

Support ticket for a Neve Pro user. The customer reports that post blocks appear for 1-2 seconds and then disappear when editing or creating posts. Pages are reported as unaffected. The attached screenshot shows List View containing an image, quote, and paragraph blocks while the main editor canvas is blank. Customer identifiers and site URL are omitted/redacted.

Reproduction notes

Likely reproduction path from code inspection:

  1. Use Neve with the block editor and a contained single-post layout.
  2. Persist neve_single_post_content_width as 0, or enable custom content width on a post and set neve_meta_content_width to 0.
  3. Open an existing post or create a new post containing normal blocks.
  4. Observe blocks appear briefly before Neve editor styles/scripts apply.
  5. Observe the main editor canvas become blank while List View still shows the blocks.

Missing from the ticket: active Neve/WordPress versions, exported theme mods, post meta, browser console output, and a direct runtime reproduction on the customer site.

Diagnosis

Conclusion

Repository inspection supports a Neve editor-width defect: when the post content width resolves to 0, Neve injects block editor CSS with max-width: 0px for normal blocks. That matches the reported timing because content can appear before Neve inline editor styles/metabox scripts finish loading, then the canvas becomes blank while List View still shows the blocks.

Where this likely occurs

  • inc/views/pluggable/metabox_settings.php:190-240, Metabox_Settings::editor_content_width: builds inline CSS for the block editor and applies max-width: %s to .wp-block. For posts it reads Config::MODS_SINGLE_CONTENT_WIDTH; for pages/other post types it reads Config::MODS_OTHERS_CONTENT_WIDTH, which explains the reported post-only behavior.
  • inc/views/pluggable/metabox_settings.php:200-204, Metabox_Settings::editor_content_width: if no per-post content width is active, a stored single-post content-width value is used directly in round( ( $meta_value / 100 ) * $editor_width ) . 'px'. A stored value of 0 produces 0px.
  • assets/apps/metabox/src/components/MetaFieldsManager.js:154-191, MetaFieldsManager.updateBlockWidth: the editor sidebar script mirrors the same behavior in JavaScript and writes .wp-block:not([data-align="full"]) { max-width: ... } after editor load. A 0 content width produces 0px in contained layouts.
  • assets/apps/metabox/src/components/MetaFieldsManager.js:393-405, RangeControl for neve_meta_content_width: the block-editor per-post control accepts min={0} and max={100}, so a zero-width value is a valid UI state for post/page meta.
  • inc/customizer/options/layout_single_post.php:184-203, Layout_Single_Post::add_sidebar_layout: the single-post Customizer control advertises min 50, but uses absint as the sanitizer, so persisted/imported/API values below 50 are not clamped server-side.
  • inc/customizer/options/layout_sidebar.php:224-245, Layout_Sidebar::add_advanced_controls: other page content width follows a separate setting, with default 100 from inc/customizer/defaults/layout.php:46-58, consistent with pages remaining visible while posts are affected.
  • Git history was not inspected because there is no version boundary or regression claim in the ticket.

Engineering notes

  • The visible symptom is a layout collapse, not content deletion. The screenshot’s List View confirms blocks are still in the editor state.
  • The likely affected contract is that content-width settings used for editor block max-width can be zero or otherwise below the usable lower bound.
  • The Customizer UI presents a 50-100 range for the single-post global content width, but persistence accepts any absolute integer. Imported settings, direct DB changes, API writes, or older data could bypass the UI range.
  • The per-post block-editor content width explicitly permits 0, and the inline editor CSS consumes it when custom content width is enabled.
  • The customer’s “new post too” detail points more toward the global single-post content-width setting resolving to zero than toward a single existing post meta value.

Test coverage status

  • No PHP/unit coverage for Metabox_Settings::editor_content_width or zero/low content-width normalization was found during inspection.
  • Existing Cypress coverage exercises normal values only: e2e-tests/cypress/integration/editor/modern/post-meta-sidebar.spec.ts:108-127 sets post content width to 60 and verifies frontend output.
  • Classic editor Cypress setup stores neve_meta_content_width: 0 in e2e-tests/cypress/integration/editor/classic/post.spec.ts:19-23, but the suite verifies frontend defaults and classic metabox behavior, not block editor canvas visibility after Neve inline styles load.

What to verify or explore next

  • Reproduce in the block editor with neve_single_post_content_width persisted as 0 and a standard post containing image/text blocks.
  • Reproduce with post meta neve_meta_enable_content_width=on and neve_meta_content_width=0 in a contained layout.
  • Compare a post and a page on the same install to confirm the page remains visible when neve_other_pages_content_width is unchanged.
  • Run the relevant editor e2e suite around e2e-tests/cypress/integration/editor/modern/post-meta-sidebar.spec.ts after adding a zero-width fixture or equivalent setup.
  • Inspect the affected site’s exported theme mods/post meta if available from support to confirm which stored width value triggers the blank canvas.

Confidence

Confidence: 82/100

The screenshot matches a code path where Neve applies delayed inline editor CSS that can collapse post blocks to zero width; repository inspection shows the post editor width path accepts/stores zero-width values without a lower-bound guard, while page defaults use a separate width path.


Source: HelpScout #3338146055
Generated by bug-report-triage workflow (ID: bug-report-triage_6a19d43d6d79f8.52336963)

Metadata

Metadata

Assignees

No one assigned

    Type

    Fields

    No fields configured for Bug.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions