ACF Fields Not Saving in WordPress? Here's the Real Fix

You added a field with Advanced Custom Fields, filled it in, hit Update — and when the page reloads, the field is empty again. Or worse, it saved fine yesterday and today the whole field group has vanished from the edit screen. This one trips up more WordPress builds than it should, because ACF quietly depends on a few things being lined up right: user capabilities, field group location rules, and (if you're on ACF PRO) how local JSON sync interacts with the database. Here's how to actually track down which one is biting you.

Symptom: What "Not Saving" Actually Looks Like

"ACF isn't saving" usually shows up as one of these, and each one points to a different cause:

• You type a value, click Update, and the field is blank on reload — but the post itself saved fine.
• The entire field group disappears from the edit screen for some posts but not others.
• Values save correctly in the classic editor screen but don't show up on the front end.
• Values save for admins but not for editors or authors.
• Everything worked until a deploy or migration, and now old data is back instead of what you just entered.

Cause 1: Local JSON Is Overwriting the Database

If you're using ACF PRO with local JSON sync (the acf-json folder in your theme), this is the single most common cause of "my changes keep disappearing." ACF PRO auto-generates a JSON file for every field group and, on load, checks whether the JSON or the database copy is newer. If a JSON file gets committed to Git with an older timestamp than a field group edit made directly on the live site, ACF will happily load the stale JSON version and your live edit is gone — not deleted, just shadowed.

Check for this first:

ls -la wp-content/themes/your-theme/acf-json/

If field group definitions live there, any change you make in Custom Fields → Field Groups in wp-admin needs to sync back to that folder (ACF shows a "sync available" notice when it detects a mismatch). If you edited a field group but never see that notice, the JSON and DB are already out of sync — and whichever one ACF decides is "newer" wins.

Cause 2: The Current User Doesn't Have Capability to Edit That Field

Field groups can be scoped by user role or capability in the field group's settings, and ACF PRO field groups can each have their own edit permissions. If an editor or author reports fields not saving but an admin can save them fine, this is almost always it. Check Custom Fields → Field Groups → [group] → Settings for any role restrictions, and separately check that the custom post type itself grants edit_post capability to that role — a mismatched capability on the post type will silently block ACF's save hook even though the rest of the post updates normally.

Cause 3: Field Location Rules No Longer Match

ACF field groups are shown (and only saved) on screens that match their location rules — post type, page template, taxonomy, or a specific post ID. If someone changed the page template, moved a post to a different category, or the site's custom post type slug changed during a migration, the field group can stop appearing on that screen entirely. When ACF doesn't render the field on the edit screen, there's nothing to submit, so it looks exactly like "not saving" even though nothing is technically broken.

Open the field group's Location rules and confirm they still match the actual post type/template/taxonomy in use. This is worth checking right after any theme switch or CPT rename.

Cause 4: A Caching Layer Is Serving the Old Admin Screen

Less common but real on cPanel hosting with OPcache or an object cache plugin: you save the field, WordPress writes the new value to wp_postmeta correctly, but the edit screen you're looking at was served from a cached fragment and shows the old value. This one is easy to rule out — check the database directly instead of trusting the browser.

In phpMyAdmin, run:

SELECT meta_key, meta_value
FROM wp_postmeta
WHERE post_id = 1234
AND meta_key LIKE '%your_field_name%';

If the value in the database is correct but the admin screen shows something else, it's a cache/rendering issue, not a save issue — clear OPcache, any object cache, and hard-refresh the admin screen. If the database value is also wrong or missing, move on to causes 1–3.

Cause 5: A Plugin or Theme Is Interfering With save_post

ACF saves field data on the acf/save_post hook, which fires alongside WordPress's own save_post. If another plugin — a page builder, a security plugin sanitizing input too aggressively, or custom theme code — hooks into the same action with a priority that runs before ACF finishes writing its data, or calls wp_update_post() again mid-save, it can clobber what ACF just wrote. This is the hardest cause to isolate because it only shows up with specific plugin combinations.

To test for it:

1. Deactivate all plugins except ACF, then try saving the field again.
2. If it saves correctly, reactivate plugins one at a time, testing after each.
3. If a page builder is involved (Elementor, Divi, Bricks), check whether the field is set to render via the builder's own dynamic content module — some builders cache field values in their own layout data separately from the ACF value.

Cause 6: The Field Isn't Registered for the Block Editor / REST API

If you're saving through the classic meta box and the value sticks, but a Gutenberg block or a headless front end (WPGraphQL, REST) shows nothing, the field data is fine — it just isn't exposed. ACF fields aren't automatically available to wp-json or block bindings; you need show_in_rest set on the field group (ACF PRO) or to register the meta key manually:

register_post_meta( 'post', 'your_field_name', array(
    'show_in_rest' => true,
    'single'       => true,
    'type'         => 'string',
) );

Add that in your theme's functions.php and the value will start showing up in REST responses without touching how it saves in wp-admin.

Quick Diagnostic Table

Prevention

• If you use local JSON, treat the acf-json folder as source of truth and always click "sync" after editing field groups directly on production — don't let two copies drift.
• Never edit field groups directly on a live site if you also deploy field group JSON from Git; pick one workflow and stick to it (edit locally → deploy JSON, or edit on the site → export JSON back to the repo before the next deploy).
• Set show_in_rest on any field group you'll ever need outside wp-admin, even if you don't need it yet — retrofitting it later means re-registering meta for every existing post.
• When testing a plugin update on a staging copy, specifically re-test custom field saves, not just page rendering — hook conflicts often show up only on save, not on load.
• Keep field group location rules documented somewhere outside ACF (a README, a ticket) so a CPT rename doesn't silently orphan a field group nobody notices for weeks.