Preview not working with Published Pages

[mj-watts]

Describe the bug

I'm using a fresh install of the latest WordPress (v5.2.1) and latest Advanced Custom Fields Pro (v5.8.1), with no other plugins installed.

• Once a page is published, changing and previewing content does not work.
• Furthermore it hides the ACF content, but when clicking preview again shows the content - but is an older version of the content, clicking preview again then hides the content and so on.

It should be noted that when a page is not published it works correctly. If I switch the page back to draft the preview works correctly.

To reproduce
Steps to reproduce the behavior:

1. Install ACF Pro 5.8.1 and create a field group with a text field called title, and show it on all posts that are pages (I can provide export of this code if needed)
2. Add <?php the_field('title'); ?> after line 17 of template-parts/content/content-page.php of twentynineteen theme
3. Create a page and write something in ACF Title like 'This is an ACF Title', then preview
4. Should see 'This is an ACF Title' on page
5. Then publish page
6. Change content of ACF Title to 'This is an ACF Title 123' and click preview
7. You should see no ACF Title
8. Then click preview again
9. Should see 'This is an ACF Title' (noting that '123' had not been added)
10. Click preview again
11. Should not see ACF Title
12. You can click preview again and again to toggle hide/show of ACF content

Expected behavior

• A up-to-date preview of the changed Advanced Custom Fields content.
• When previewing the page multiple times WordPress should not be toggling showing/hiding of Advanced Custom Fields content

Screenshots

Preview working on unpublished pages:

Preview not working on published pages:

Previewing multiple times toggles the content on and off:

Desktop (please complete the following information):

• OS: OSX
• Browser chrome
• Version [74.0.3729.169 (Official Build) (64-bit)]

Additional context

• Please add the version of Gutenberg you are using in the description: Whatever is used in WordPress 5.2.1
• Here is a JSON export so the custom fields can be easily recreated, just save as a file and import using Custom Fields > Tools > Import Field Groups:

[
    {
        "key": "group_5cf7bf8106d4d",
        "title": "Page",
        "fields": [
            {
                "key": "field_5cf7bf875b9ca",
                "label": "Title",
                "name": "title",
                "type": "text",
                "instructions": "",
                "required": 0,
                "conditional_logic": 0,
                "wrapper": {
                    "width": "",
                    "class": "",
                    "id": ""
                },
                "default_value": "",
                "placeholder": "",
                "prepend": "",
                "append": "",
                "maxlength": ""
            }
        ],
        "location": [
            [
                {
                    "param": "post_type",
                    "operator": "==",
                    "value": "page"
                }
            ]
        ],
        "menu_order": 0,
        "position": "acf_after_title",
        "style": "default",
        "label_placement": "top",
        "instruction_placement": "label",
        "hide_on_screen": [
            "permalink",
            "the_content",
            "excerpt",
            "discussion",
            "comments",
            "revisions",
            "slug",
            "author",
            "format",
            "page_attributes",
            "featured_image",
            "categories",
            "tags",
            "send-trackbacks"
        ],
        "active": true,
        "description": ""
    }
]

[talldan]

Thanks for the details @altescape, really great bug report.

Out of interest, if you save the post (cmd+s/ctrl+s) before clicking preview do you see the latest changes? If so, that might be a (not ideal) workaround.

The issue might be that the fix (#14877) for the previous preview issue (#12617) involved disabling the saving of metaboxes when the preview button is clicked. Unfortunately the metabox save process was causing post revisions to be deleted.

I created an issue #14900 to consider ways to re-enable metabox saving when previewing. It's not a simple thing to fix unfortunately.

[mj-watts]

Thanks for the heads up @talldan - I'll have a look also at the issue you created.

cmd+s didn't work, WordPress only allows saving when I've edited WordPress blocks and not metaboxes, thank you for the tip though - I'll wait for further updates regarding this.

[corywebb]

I am seeing a similar issue without ACF. Preview is not working on an already-published post if an autosave of the post exists. Here are the steps to reproduce:

1. Create a post.
2. Publish the post.
3. Close the post editor, and then re-open the post.
4. Make a change to the post, and then close the editor without saving. You should see an alert that asks if you want to leave the page. Click the "Leave" button to leave the page.
5. Re-open the post again, and note the "There is an autosave..." message at the top of the editor.
6. Make a different change to the post, and click the "Preview" button.
7. Note that the preview does not show the change(s) made in step 6.

The preview works for me when an autosave does not exist, but it does not work when an autosave exists.

[tomjn]

@altescape is there an equivalent ACF support post? It'd be good to cross reference and debug faster. It's possible this is an ACF specific issue, but if it isn't it'd be good for debugging to track down where things go wrong and improve Gutenberg accordingly

[amanda-t]

@tomjn Most recent thing I've seen from ACF is AdvancedCustomFields/acf#186

[corywebb]

@tomjn this issue isn't just happening with ACF. See my previous comment above: #16006 (comment)

[dartiss]

This issue is occurring for a WordPress VIP client. If anyone within the Automattic Gutenberg team are able to look at this, it would be appreciated.

[jweston491]

This bug is still occurring for me.

Using Twenty-Nineteen with 5.2.2 with ACF Pro 5.8.2

[andreabrunato]

This bug till occurring for me, only in preview of published posts.
Using Sage Roots theme (customized by me), WP 5.2.2 e ACF Pro 5.8.2.
Both in local server and online.

[newhope]

Still occurring for me.
Need to switch back to classic editor.

[cyberphen]

Can confirm, happening with me.

[ejke]

Adding my voice, occurring to me as well.
Wordpress 5.2.2, ACF Pro 5.8.3.

I solved the problem temporarily by installing and activating Disable Gutenberg plugin, but as I would like to be able to use both ACF and Blocks, it's not a long-term solution.

[atomiccherry]

Experiencing same issue as well.

[df165]

Also experiencing this issue. Edit: ejke's solution of installing Disable Gutenberg plugin worked for me.

[jg314]

A few of us are taking a look at this at WordCamp US Contributor Day. We're able to replicate this issue in a number of scenarios within WordPress 5.2.4.

• We tested with both an Advanced Custom Fields meta field, but also with a generic meta field added via add_meta_box().
• We tested with the Gutenberg plugin v6.8.0 both activated and deactivated.

In every case, the preview works correctly when the post is a draft, but once published, the preview doesn't update the meta field content.

[joppuyo]

Hey, I also have this problem. If I enable Classic Editor the preview works properly but when using Gutenberg the preview does not update custom fields if the post has been published.

In my opinion, Gutenberg should also save post meta changes when creating a preview as it worked before.

While "Just make everything a block" is probably the "Gutenberg way" of solving things, it doesn't work in all cases. Let's say you have a custom post type called "Event" and you want to use Gutenberg editor with it. You probably want custom fields called start_time and end_time so you can properly query the posts elsewhere on your site. You also probably want to show these fields in the post template. If you would save this data into blocks, it's impossible to query since it's stored as JSON in the post content.

So this bug prevents using preview properly when using custom fields and Gutenberg together.

[jnicol]

This longstanding bug still exists in April 2020: Changes to custom fields are not reflected when previewing a published post. I tested with WP 5.4, 2020 theme and all plugins disabled.

Although this bug report specifically mentions the ACF plugin, it affects all custom fields.

The only "solution" I can find is to install the Classic Editor plugin.

[hubertnguyen]

Actually, it's my post content updates that are not showing in the preview. It's really weird and creates a lot of friction in the workflow.

Solution for now: if I save and refresh the current /wp-admin/post.php?post=[POSTID]&action=edit page, the preview works again, until next time. Sigh.

[thomascharbit]

Is there any update on this issue?
Any workaround?

It's been a while..

[KevinRay]

Seeing this with WP5.4. Installing the Classic Editor plugin worked for us.

[Erutan409]

I have the Classic Editor plugin installed and this is still occurring for me. Latest WordPress version.

[rahulsg91097]

I was facing the same issue and was able to tackle this issue by using this plugin: WP Revisions Control.

[lnikell]

@rahulsg91097 it won't help because it does not fix the Gutenberg issue. So I suppose you also disabled the Gutenberg editor.

[EdithAllison]

Following as I'm having the same problem. We are using ACF to add fields to page templates and Gutenberg editor for the main content part. Preview is broken due to missing ACF fields. Disabling Gutenberg is not an option as we also need to use custom blocks and patterns. I don't have a solution but a fix would greatly improve our usage of WP.

[tolkadot]

I've just had to install the classic editor to overcome this issue on a new site. So disappointing.
Will this be addressed before support for the classic editor plugin expires on December 31, 2021 ?

[todeveni]

Will this be addressed before support for the classic editor plugin expires on December 31, 2021 ?

Classic editor support is extended at least through 2022.

[TimDix]

I tried to use the Yoast Duplicate Post plugin as a workaround for this issue. There's a Rewrite & Republish feature which lets you save the ACF Meta fields to the draft, and therefore I can get working previews. And I found it worked even better than expected. The Preview works fully without saving drafts and includes ACF Meta updates.

Workaround Steps:

1. Install Yoast Duplicate Post
2. Go to plugin settings and enable it for the post type which uses ACF Meta fields and gutenberg editor
3. Click Rewrite & Republish on a post of your choice
4. Update your ACF field data
5. Click Preview, Preview in new Tab
   You should see your ACF Meta fields are now properly updated in the preview!

https://wordpress.org/plugins/duplicate-post/

Not an ideal workaround since it requires extra steps, however it's workable and can be built into workflow to just always Rewrite & Publish for updates.

Perhaps this workaround can help identify a basis for an official solution?

WordPress Version 5.8.2
ACF Pro Version 5.11.1
Yoast Duplicate Post Version 4.2

[okadots]

Having the same issue where ACF fields that are not blocks don't update in preview once a page is made live.

The solution posted here (the one from darkly77 at the bottom) is working for me.
https://support.advancedcustomfields.com/forums/topic/custom-fields-on-post-preview/

[stefanfisk]

I just now discovered that I am also affected by this when previewing pages that use ACF blocks. Said workaround seems to work.

[lichtmetzger]

The solution posted here (the one from darkly77 at the bottom) is working for me. https://support.advancedcustomfields.com/forums/topic/custom-fields-on-post-preview/

It does work somewhat because it shows the current state of a site before doing any further edits. New changes are not reflected in the preview though, making the preview at least do something, but still not being very useful.

The preview seems to work fully when creating a new page, though, which is nice.

[kory-northrop]

Another year has gone by without any updates. What is the status of a fix for this issue? It still exists....

[dipak-webo]

Guys I wonder, when autosaved it creates a new row in the posts table with a unique ID, why can't save meta values referencing to this ID? Isn't it simple? My project actually heavily depends on meta values and when I can't preview them, it's so weird.

[tripflex]

Almost 5 years later and now Gutenburg is the default editor, how is this not something being looked at all?? This is not just an issue with ACF, it's an issue with ANY custom meta boxes.

Is WordPress/Gutenburg of the opinion that these things should be handled by plugins (and not handled natively like it is with classic editor)?

[isuke01]

I wonder if this ever gonna be "fixed".

[adamsilverstein]

we do revision post meta now, so this should be resolved or resolvable.

[SiteBoltsAdmin]

We noticed today that WordPress's "Preview Changes" feature wasn't working correctly for ACF fields; the preview was showing their published values rather than the previewed values.

We tried out several suggested PHP snippets but found that they didn't resolve the issue.

After seeing this suggestion:

define( 'WP_POST_REVISIONS', 3 );

We did some testing and confirmed that the issue occurs when post revisions are disabled. In our case, it was due to our WordPress host (WPEngine) disabling post revisions by default. We were able to fix it by contacting their support and having them set the number of post revisions to 3.

[adamsilverstein]

We did some testing and confirmed that the issue occurs when post revisions are disabled

So you can confirm this works fine when revisions are enabled? thinking we can close this ticket as resolved.

[jasonbahl]

@adamsilverstein thanks for following up!

I tested my use case above (#16006 (comment)) and core meta that is revised, such as footnotes, appears to work as I would expect.

However, ACF meta does not work as expected, but I believe this is something the ACF team will need to work on implementing now that there is formal core support for meta revisions.

Here's an example of my use case of using WPGraphQL to query for a Published Post and a Preview of the same post with unpublished changes.

I used footnotes as an example, and added a footnotes field to the WPGraphQL Schema like so:

add_action( 'graphql_register_types', function() {

	register_graphql_field( 'post', 'footnotes', [
		'type' => [ 'list_of' => 'String' ],
		'description' => 'Testing footnotes',
		'resolve' => function( $post ) {
			$footnotes = get_post_meta( $post->ID, 'footnotes', true );
			$footnotes = json_decode( $footnotes, true );
			$notes = [];
			foreach ( $footnotes as $note ) {
				$notes[] = $note['content'];
			}
			return $notes;
		}
	]);

} );

I also had to filter WPGraphQL to tell it that the footnotes meta key is revised (ideally WPGraphQL should be able to detect this from the meta registry - I just opened this issue to address: wp-graphql/wp-graphql#3260):

add_filter( 'graphql_resolve_revision_meta_from_parent', function( $default, $object_id, $meta_key, $meta_value ) {
	if ( 'footnotes' === $meta_key ) {
		return false;
	}
}, 10, 4);

I then published a post with some footnotes, and then made some unsaved changes to the footnotes and previewed it.

I was able to query and see both the published footnotes and preview footnotes.

I think from my perspective, this is likely resolved from WordPress core / gutenberg standpoint, and at this point (at least for my specific use case) the ACF team will need to work on some changes to ensure meta fields are stored on revisions in the same way core fields like footnotes are, as the ACF-specific use case is not working for me, but I believe there's enough evidence to show that ACF should now be able to hook into the block editor in some way and revision meta similar to how they revise meta on non-block-editor posts.