Gutenberg: Preview not working with Published Pages

[altescape]

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 https://github.com/WordPress/gutenberg/issues/14900 to consider ways to re-enable metabox saving when previewing. It's not a simple thing to fix unfortunately.

[altescape]

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 https://github.com/AdvancedCustomFields/acf/issues/186

[corywebb]

@tomjn this issue isn't just happening with ACF. See my previous comment above: https://github.com/WordPress/gutenberg/issues/16006#issuecomment-502834583

[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.

[hoangemini]

I'm also getting this issue, hoping someone knows how to fix it :(

[jamal08bd]

More than a year seems this bug still exist.

And this is not only with ACF but also with any custom meta field.

Short description of the bug:
The preview works correctly when the post is a draft, but once published, the preview doesn't update the meta field content unless you update any NATIVE field or click the UPDATE button.

[PogHallam]

We were experiencing this issue for a custom post type.
Problem:
Preview worked on draft but not published posts (CPT).
Fix:
Added the supports => 'revisions' element to register_post_type() args.

$args = array(
        ...
        'supports'           => array( 'title', 'thumbnail' ), // Before
        'supports'           => array( 'title', 'thumbnail', 'revisions' ), // After
        ...
);
register_post_type( 'my_cpt', $args );

After this, the preview displays edited ACF fields correctly.

[dtipson]

Still the case in both Gutenberg and classic, afk, and affects any changes to custom fields, not specific to ACF.

[garyc40]

Confirming that I'm seeing this issue as well with Pages, across all sites. Using ACF and Gutenberg.

[jmccall75]

Can someone confirm that this is still an ongoing issue and whether or not there's a fix? I've been searching around, and it seems like we just have to wait on a patch from the Gutenberg team but trying to confirm that. Thanks.

[matthewmcvickar]

@talldan Can you provide an update on the status of this bug? It appears the central issue is that post meta is intentionally not saved during preview, because doing so deletes the revision that would otherwise be created at the time of preview. Is that correct? In any case, this bug seems to have existed since late 2018, though it was briefly fixed after the initial report (#12617) and then that fix was reverted (which is #14900 is tracking). For any site with content that includes post meta, this bug is really disruptive, so I'd love to have some idea of its priority. Thank you!

[jasonbahl]

I've been working on adding proper support for previewing data in WPGraphQL, and I have support for previews with meta working when using the Classic Editor, but because of this bug I'm unable to provide support for exposing previews when using Gutenberg.

You can see the workflows I'm using to test with Classic Editor here, and things are working as expected: https://github.com/wp-graphql/wp-graphql-acf/pull/153

Below are the same scenarios as outlined in that issue, but with Gutenberg active and how the behavior is much different and unexpected:

Preview New Unsaved Post

I created a new Post using Gutenberg and set an ACF Text field and ACF Text Area field to the values Unpublished Post as seen in the screenshot. Then clicked Preview (without saving or publishing):

This takes me to the URL: http://acf2.local/?p=753&preview=true, so I can now use ID 753 to query with GraphQL.

{
  post(id: 753, idType: DATABASE_ID, asPreview: true) {
    id
    databaseId
    title
    content
    acfPostFieldGroup {
      text
      textarea
    }
  }
}

Here, we can see that the unpublished post is properly showing the ACF fields.

Previewing a Draft Post

Now, I updated the ACF field values to both be Draft field and clicked "Save Post"

This saves the post and redirects the Admin URL to the following: http://acf2.local/wp-admin/post.php?post=753&action=edit

We can use the same ID, 753, to query the data again:

{
  post(id: 744, idType: DATABASE_ID, asPreview: true) {
    id
    databaseId
    title
    content
    acfPostFieldGroup {
      text
      textarea
    }
  }
}

And we get the following results:

Now, if I update the ACF field values on the Draft post to Previewing a changed Draft field and click "preview" without clicking save changes. This returns the following:

In the screenshot we can see that the values of the draft post and the preview of the draft post are the same values. This is incorrect behavior. The value of the Post (id: 753) should be Draft field still, and the preview node (id: 764) should be Previewing a changed Draft field as seen in the examples with the classic editor (https://github.com/wp-graphql/wp-graphql-acf/pull/153).

When looking at the database, the meta values for Post 753 and 764 are identical, and this is incorrect behavior.

When clicking Preview in Gutenberg the Preview post (764) should be updated with the new meta values, but the previously saved Draft Post should _not_ be updated until the user clicks Save (to match behavior with Classic editor).

Previewing Published Post

Now, if I Publish the Post with the ACF Field values as Published value and query, I see the following:

I can see the preview Post is now ID 774.

I can see the meta in the database for that Post:

Now, if I change the values of the ACF fields to Unpublished and click Preview again:

It creates a new autosave post with ID 779

And no meta is associated with Post 779:

And a GraphQL Query for the published post and it's preview node looks like so, with null values for the ACF fields:

[talldan]

@matthewmcvickar The problem still exists unfortunately.

though it was briefly fixed after the initial report (#12617) and then that fix was reverted (which is #14900 is tracking).

12617 is the issue relating to post revisions being deleted that you mentioned in the first part of your comment. The side-effect of the fix (#14877) for that is this bug (which is really the same as #14900).

The WordPress core code for saving meta values is a little outside my area of knowledge, but comments (https://github.com/WordPress/gutenberg/pull/14877#issuecomment-481322694, https://core.trac.wordpress.org/ticket/46076#comment:6) suggest that the work on https://core.trac.wordpress.org/ticket/20564, is the way forwards.

[jasonbahl]

I'm curious why an 8-year old ticket is the proposed solution to fix behavior that is caused by Gutenberg. Things work with classic editor and don't work with Gutenberg. This doesn't seem to be related to Alex King's proposal for a more formal meta revision framework. It's a bug with Gutenberg.

I'm all for a more formal framework for revising meta, but Gutenberg has a bug to fix regardless of some bigger revision framework.

[talldan]

@jasonbahl While Gutenberg uses the WordPress REST API for most of its operations (using the posts REST endpoint to create revisions for previews), it still has to rely on legacy code to save post meta (an HTTP request to /wp-admin/post.php). I believe the goal to introduce post meta revisions helps solve this as the two systems would work more harmoniously rather than in conflict as discovered in #12617.

While you're repeatedly mentioning this as a Gutenberg bug in your comments, in terms of where the code lives it's a WordPress core issue. Perhaps a separate core trac ticket needs to be made to look at alternative fixes to this issue if there's not much happening on https://core.trac.wordpress.org/ticket/20564. Looking at the github repo for the post meta revisions project, it looks like there has only been one commit this year:
https://github.com/adamsilverstein/wp-post-meta-revisions/commits/master

If you're interested in digging deeper, https://github.com/WordPress/gutenberg/issues/12617 has most of the history on why this trade-off with not saving post meta during previews came about.

[joppuyo]

I looked into this some more and correct me if I’m wrong but I don’t think WordPress core provides a way to preview post meta fields.

However ACF has a workaround where post meta fields are attached into the temporary preview post. This works fine with the classic editor but there’s a bug in Gutenberg that causes this feature to no longer work.

I think this is why the preview works with drafts, since the post meta is saved into the same post id, there’s no issue.

With published posts the preview is saved to the temporary preview post id and because of this bug this feature no longer works.

[dtipson]

@jasonbahl I've also tried to look into workarounds for this, and I'm pretty sure it's a core issue, as it plagues Classic Editor mode as well. ACF can bypass the problem with its own workaround when something is in draft, but once it's published, the behavior of the preview is erratic/generally does not work.

[adamsilverstein]

core/classic suffers from a different problem for published posts: meta on published posts is updated on the parent post when changed and previewed. So yes, previews work - with the unintended side effect of updating your live site. See https://core.trac.wordpress.org/ticket/20299

The underlying issue is complex, but boils down to this: previews are a view of a post with data provided from an autosave fired for the preview. Autosaves are a type of revision, and revisions currently do not support meta in core. For this reason, previewing meta changes is difficult.

For the case of the featured image which is stored as an id in post meta, we actually work around this by passing the id as a query variable (_thumbnail_id=450), then using that in the preview.

I have been working on this issue for years, however I was unaware that meta saving was removed for previews in https://github.com/WordPress/gutenberg/pull/14877.

I do see a path forward here:

• Enable meta on revisions.
• Revision all meta for autosaves (otherwise revisioning of meta is opt-in).
• Include all meta data in autosaves.

I'll work on a patch as I have time.

[joppuyo]

I think the root cause for this issue is that using classic editor when I preview a post there is a POST request that contains data for the request (Post name, content, etc). A new temporary post (is this the same as autosave?) is created with the preview data. This request is redirected to that preview page.

Because there is no support for post meta revisions in the core, ACF (and I presume also other plugins like Meta Box and Toolset) use that same POST request to pass their own meta field data and attach it to the temporary post. That's why you can preview the meta fields using the WordPress preview when using classic editor.

Gutenberg doesn't use a POST form request to send the data when previewing a post, it uses an XHR request to the REST API. When the REST API request is complete, the preview page is opened in a new window.

According to #12617 , Gutenberg used to have a compatibility feature with meta boxes so there were two different requests, a POST request for meta boxes and another for the REST API. However, there was a race condition where sometimes the requests completed in the wrong order. Instead of fixing the race condition, the meta boxes POST request was removed in #14877 .

Because of this, previewing ACF meta fields doesn't work with Gutenberg while it does work with the classic editor.

So the problem is not that there is no support in core for meta revisions but the fact that the POST request for meta boxes is not sent.

I don't really know what's the best way to fix this. Either Gutenberg should provide compatibility for meta fields POST request (by fixing the race condition) or meta field plugins like ACF need to be rewritten to use the REST API.

[pristas-peter]

I think it could be solved this way:

• install a custom rest middleware with apiFetch.use and then check if it is a rest call to create update revision/autosave
• call document.querySelectorAll('form') and create FormData object of all the fields
• send the POST request to wp-admin/post.php before(after) the intercepted rest call will start (did finish)

EDIT: or do the last part in he rest controller in PHP when the revision request is handled

[akeith2002]

Does anyone know what the current status of this is? @jasonbahl - wasn't sure if you implemented a fix for this in some way?

Thanks all in advance!

[pristas-peter]

I havent had time to look at this, but check out this README:
https://github.com/WordPress/gutenberg/blob/0ad0414e7a469254ef1ad105fdcf14248a986686/docs/designers-developers/developers/backward-compatibility/meta-box.md

[dkadezabek]

We were experiencing this issue for a custom post type.
Problem:
Preview worked on draft but not published posts (CPT).
Fix:
Added the supports => 'revisions' element to register_post_type() args.

$args = array(
        ...
        'supports'           => array( 'title', 'thumbnail' ), // Before
        'supports'           => array( 'title', 'thumbnail', 'revisions' ), // After
        ...
);
register_post_type( 'my_cpt', $args );

After this, the preview displays edited ACF fields correctly.

@PogHallam This helped me, thanks.

[adamsilverstein]

EDIT: or do the last part in he rest controller in PHP when the revision request is handled

@pristas-peter this sounds more ideal - this way all updates occur in one request, avoiding the race condition issues we had when trying to split this into two requests (previously).

update revision/autosave

To attach meta to an autosave revision, we sill need to add support for meta revisions.

[joppuyo]

To attach meta to an autosave revision, we sill need to add support for meta revisions.

As I said this is already handled by the the third party plugin, the only regression in Gutenberg the the lack of a request containing the meta box values.