Neve Options (page meta sidebar) silently fail to persist on some sites

[milicavs]

Summary

On a small number of sites, the per-page Neve Options (Disable Title, Disable Header/Footer, Container, Content Width, Title Alignment, i.e. the neve_meta_* post meta saved from the editor sidebar) silently fail to persist. The editor shows "Page Updated" with no error, but the values revert when the editor is reloaded and never apply on the frontend. Core fields on the same save (content, title, featured image, tagline) persist correctly.

This has been reported at least 5 times over the past year through wp.org and HelpScout. Each report was handled in isolation, could not be reproduced on clean test sites, and was closed unresolved. Filing this so the pattern is tracked in one place and new reports get attached here.

Symptom signature (consistent across all reports)

• Toggle a Neve Option in the editor sidebar, click Update, get the success notice
• Reload the editor: the option has reverted; frontend never changes
• No JS console errors, no failed requests reported by users
• Variant reported twice: settings save correctly ONCE, then all subsequent changes revert ("locked")
• One reporter found that writing the same neve_meta_* values directly via the Meta Box plugin persists AND renders correctly on the frontend, so DB writes and frontend reads are healthy; the failure is specific to the editor save path
• One reporter also saw global Customizer title alignment "not applying"; this may be masking by stored per-page neve_meta_title_alignment values overriding the global setting (which the user then cannot clear because of this bug)

Reports

Date	Channel	Product	Environment
2025-08-07	HelpScout 3029298356	Neve Pro 3.1.2	WP 6.8.2, PHP 8.2, DreamHost (nginx + Rocket-Nginx + Autoptimize), Neve child theme, Otter + Otter Pro 3.1.0
2026-03-19	wp.org thread	Neve free	unknown; "saves once then locks" variant
2026-07-30	wp.org thread	Neve free 4.2.10	WP 7.0.2→7.0.3, PHP 8.3, MariaDB 11.8, Hostinger (LiteSpeed), Otter 3.2.1, Starter Sites 1.4.3, no child theme, no drop-ins
2026-08-09	HelpScout 3413032736	Neve Pro	Hostinger (LiteSpeed + Cloudflare + FlyingPress), Otter; user says issue is longstanding; "locked" variant
2026-08-10	HelpScout 3413659384	Neve Pro	Kinsta + Cloudflare, Otter 3.2.1, Starter Sites; Meta Box direct-write workaround confirmed working

Ruled out

• Release regression: reports span a full year (WP 6.8.2→7.0.3, Neve Pro 3.1.2→3.2.x). Diffs of Neve 4.2.9/4.2.10, Neve Pro 3.2.7–3.2.9, Otter 3.2.0/3.2.1, Starter Sites 1.4.2/1.4.3 contain no changes to the metabox/meta save path
• Hosting/caching: 4 different hosts and 4 different caching stacks across reports
• On the 2026-07-30 wp.org case specifically (user was very cooperative): Cloudflare paused (no change), host page cache cleared, hPanel object cache off, no object-cache.php drop-in, no drop-ins at all, browser extensions ruled out via incognito, plugin conflict ruled out via Health Check Troubleshooting Mode, theme files ruled out via delete + reinstall of Neve, WP reinstalled itself as part of 7.0.2→7.0.3 auto-update with no change
• Starter Sites: not installed on the 2025 case
• Child theme: only present on 1 of 4 verifiable sites

Common factor on all 4 verifiable sites besides Neve: Otter (which loads editor JS), with the caveat that Otter is present on most Neve sites anyway.

Not reproducible so far

Attempted on two Hostinger sites (one long-standing, one fresh): WP 7.0.3 + latest Neve + Neve Pro + Otter 3.2.1 + Starter Sites 1.4.3 incl. a starter site import, LiteSpeed Cache with "Cache REST API" and "Cache Logged-in Users" both ON. Neve Options and Customizer settings save and apply correctly in all combinations.

Mechanism hypothesis

neve_meta_* keys are registered on init in inc/admin/metabox/manager.php (neve_register_meta()), with show_in_rest => true and the control list passing through the neve_sidebar_meta_controls filter. If registration is absent or incomplete at REST request time, WordPress silently drops those fields from the editor save payload and omits them from context=edit responses. That failure mode produces exactly this signature: success notice, silent revert, no errors, direct DB writes still working, frontend (plain get_post_meta) still rendering directly-written values.

What could make registration fail only on certain sites (custom code on the filter, mu-plugin interference, stale opcache serving mixed file versions after auto-updates, or something else) is the open question. An editor-JS-side failure (meta edits never entering the save payload; possible interaction with other editor plugins such as Otter) is the alternative; the diagnostics below distinguish the two.

Diagnostics for the next affected site we get access to

1. Logged in as admin, open /wp-json/wp/v2/pages/<ID>?context=edit and check whether neve_meta_* keys exist in the meta object. Absent = server-side registration broken. Present = editor JS side
2. Capture the save request (POST to wp-json/wp/v2/pages/<ID>): does the payload include the neve_meta_* fields, and does the response echo them back?
3. Flush opcache / restart PHP (PHP version toggle on Hostinger, Restart PHP on Kinsta), retest
4. Customizer check: does a control retain its value after publish + reopen, and does the global title alignment apply on a brand-new page (per-page meta override masking test)
5. Ask when the issue started and whether it followed an update

Site access has been requested from the two active Pro customers; will update here with findings.

[milicavs]

Root cause found

The reverting Neve Options are caused by WordPress core's legacy "Custom fields" editor panel (three-dots menu → Preferences → Advanced → Custom fields). It is a per-user preference, persisted server-side in usermeta, which is why the bug follows an affected user across browsers and computers for years while never reproducing for anyone else on the same site.

Mechanism

When the Custom fields panel is enabled, it renders as a classic meta box, so the block editor performs a two-step save:

1. The normal REST save (POST /wp-json/wp/v2/pages/<id>) — this correctly saves the neve_meta_* values. Confirmed via HAR capture on an affected site (with the owner's permission): the request payload contained the new value and the response echoed it back.
2. Immediately after, the editor fires the metabox reconciliation request (POST post.php?meta-box-loader=1). The Custom fields panel's form re-submits every existing postmeta row with the values it had when the editor page was loaded (meta[<row-id>][key] / meta[<row-id>][value]). Core's edit_post() processes those rows and overwrites the meta the REST save just wrote.

The user watches their toggles snap back mid-save (the second request completes moments after the first), with a success notice and no errors anywhere.

Reproduction on a clean site (verified on a fresh TasteWP install, WP 7.0.3 + Neve 4.2.10, no other plugins)

1. Fresh WordPress + Neve. Create and publish a page.
2. Open it in the block editor, set a Neve Option (e.g. enable Custom Content Width, set 70), Update. This first save works — see note below.
3. Three-dots menu → Preferences → Advanced → enable Custom fields → "Show & Reload Page". The panel at the bottom now lists neve_meta_enable_content_width = on, neve_meta_content_width = 70, etc.
4. In the Neve Options sidebar, change the width to 100 (or toggle Disable Title). Click Update.
5. Watch the sidebar during the save: the value snaps back. Reload to confirm it reverted. In DevTools → Network you'll see the two-request signature from the mechanism section.
6. Disable the Custom fields panel, change the option again, Update: it persists.

Why the first save works (and why two reporters described "saves once, then locked"): on a page with no neve_meta_* rows yet, the Custom fields panel has nothing stale to re-submit, so the first save survives. Once the rows exist, every subsequent change is clobbered by the page-load snapshot.

Why this evaded diagnosis for a year

• Per-user usermeta preference: invisible to plugin-conflict testing (it is core, not a plugin), theme reinstalls, cache purging, browser/incognito tests, and any tester using their own account.
• Silent: the REST save genuinely succeeds; the overwrite happens in a second request that also "succeeds".
• Several of the options produce no visible frontend change in common configurations (e.g. title alignment while Disable Title is on; sidebar "Inherit" on a no-sidebar site), so even successful saves looked broken to reporters and reverting saves looked identical to caching issues.

This accounts for all five linked reports, including the Meta Box direct-write workaround one reporter found (writes made outside the editor session have no stale snapshot to fight).

Suggested fix

Mark the neve_meta_* keys as protected via the is_protected_meta filter (in addition to the existing registration in inc/admin/metabox/manager.php::neve_register_meta()). Protected meta:

• is not listed by the Custom fields panel, closing the stale-resubmit hole for every user at once;
• remains fully readable/writable through the REST API for the editor sidebar, since it is registered with show_in_rest and an auth_callback.

Note the general class of conflict: any classic meta box that manages the same keys (the Meta Box plugin, ACF with matching field names, custom code) causes the identical stale overwrite of sidebar edits. is_protected_meta closes the core Custom fields case; the docs/support macro should mention the general shape for third-party field-group cases.

Support-side workaround (per affected user)

Three-dots menu → Preferences → Advanced → switch Custom fields off → "Hide & Reload Page". Fix instructions have been sent to the three active reporters; confirmations pending.