Gutenberg: Preview fails to display edits on published posts when metaboxes are visible in Gutenberg

Created on 5 Dec 2018  ·  129Comments  ·  Source: WordPress/gutenberg

The preview button in the Gutenberg editor in Wordpress 5 RC3 doesn't display unsaved edits.

Reproduced by creating and saving a page, then edit the page and click preview. The preview page only shows the original page and not the additional edits.

[Feature] Meta Boxes [Feature] Saving [Priority] High [Type] Plugin Interoperability
Source
picture davidAIS
👍17

Most helpful comment

I fixed my website in the following way.

  1. not change post_modified_gmt if REQUEST_META_BOX_UPDATES action
add_filter( 'wp_insert_post_data', function ( $data ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        unset( $data["post_modified"] );
        unset( $data["post_modified_gmt"] );
    }

    return $data;
} );

or

  1. set autosave's post_modified_gmt = original post's post_modified_gmt +1 sec
add_action( 'save_post', function ( $post_id, $post ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        $autosave = wp_get_post_autosave( $post_id, get_current_user_id() );
        if ( $autosave ) {
            $filter = function ( $data ) use ( &$filter, $post ) {
                remove_filter( 'wp_insert_post_data', $filter );
                $data["post_modified"]     = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified ) + 1 );
                $data["post_modified_gmt"] = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified_gmt ) + 1 );

                return $data;
            };
            add_filter( 'wp_insert_post_data', $filter );
            wp_update_post( $autosave );
        }
    }
}, 10, 2 );
picture technote-space on 6 Apr 2019
👍6 🚀2

All 129 comments

I did a quick test with WordPress 5.0-RC3-43967 and do not see the same problem.

preview-test

Can you tell me a little more about your testing?

Are you testing previews of a draft or a published post?

Did you press "Preview" each time or save and try reloading a previously opened preview?

Are you making changes to the post content or are you making changes to things like post settings and meta data?

Would it be possible for you to provide a short list of exact testing steps?

designsimply picture designsimply on 5 Dec 2018

I tested both.

The initial test was on a client site where I was doing a trial install of WordPress 5 in which I attempted to edit an existing page. Edits on that page didn't show up in preview. The only way to see then was to save the page.

As a more objective test I then created and saved a new page, then went back and edited the page. The edit didn't show up in preview. (This test was in a page not a post - I’ve not tried the test for a post. Not sure if that would make a difference though)

Fro what I can see of your recording you’re doing a preview of the initial page prior to saving which is different from what I encountered.

Hope that helps clarify.

On 5 Dec 2018, at 16:30, Sheri Bigelow notifications@github.com wrote:

I did a quick test with WordPress 5.0-RC3-43967 and do not see the same problem.

Can you tell me a little more about your testing?

Are you testing previews of a draft or a published post?

Did you press "Preview" each time or save and try reloading a previously opened preview?

Are you making changes to the post content or are you making changes to things like post settings and meta data?

Would it be possible for you to provide a short list of exact testing steps?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

davidAIS picture davidAIS on 6 Dec 2018
👍1

Thanks for the clarification! There are actually more scenarios than you might think if you consider autosaves vs "Save Draft" and draft vs published and post vs page and all the combinations thereof. My test had 3 cases: new post -> preview, edit draft -> preview, save & publish then edit then preview.

Sounds like your testing steps are:

  1. Create page.
  2. Save.
  3. Go to Pages list.
  4. Re-open page.
  5. Make an edit to the text.
  6. Click Preview.

Testing note: since publishing wasn't mentioned, try with a draft as well as a published page.

designsimply picture designsimply on 6 Dec 2018

I'm sure there are lots of scenarios.

This is mine.

I have a previously published page (as it happens created before the site was updated to Wordpress 5) that now requires an update.

Having made the edit, if I click Preview the update is not displayed. It's therefore not possible to check the progress of a set up updates on the page without publishing the page.

That is not a safe way to edit the content and therefore renders the new editor unusable in this real world scenario.

davidAIS picture davidAIS on 7 Dec 2018

I ran another test after upgrading a different site to WordPress 5.0 and I can still see previews working normally. I tested with Firefox 63.0.3 on macOS 10.13.6 and I tried with a draft as well as with a previously published post. Please have a look and let me know if I'm still missing anything from my testing steps!

12617-44s

5.0 was just released, so I suggest updating and uninstalling the Gutenberg plugin if you have it (you don't need it any more with 5.0). If you're still having trouble after that, I would suggest checking for a plugin or theme conflict by temporarily disabling all plugins and switching to the default theme as a test to see if the problem still happens under those conditions. If your test setup was already like that, we'll need to try to think of what else could be the source of the trouble in your case.

Sometimes OS or browser version matter for cases like this. I tested with a Mac, and if you let me know you're OS and browser versions, I can test again from a more similar setup to you.

designsimply picture designsimply on 7 Dec 2018

I’ve also had this problem pretty frequently in wp 5.0, can’t say the exact scenario but it feels kind of random and I’ve never had it when using the Gutenberg plugin the last 5 months. Will try to make a proper repro tomorrow.

Using
MacOS
Chrome

slimmilkduds picture slimmilkduds on 8 Dec 2018
👍2

Thanks @slimmilkduds!

I also just closed #12717 as a duplicate and wanted to note it also includes a video.

designsimply picture designsimply on 12 Dec 2018

Re:

5.0 was just released, so I suggest updating and uninstalling the Gutenberg plugin if you have it (you don't need it any more with 5.0). If you're still having trouble after that, I would suggest checking for a plugin or theme conflict by temporarily disabling all plugins and switching to the default theme as a test to see if the problem still happens under those conditions. If your test setup was already like that, we'll need to try to think of what else could be the source of the trouble in your case.

Repeating the test with 5.0, without plugins and using a default theme made no difference to the outcome. I am still not seeing the edits when I click the preview button.

For info I'm using Chrome 70.0.3538.110 and MacOS 10.13.6

I note that you've closed ticket #12717

In fact that sheds additional light on this and I can confirm the findings in that ticket. Initially the preview button doesn't display the edited contents as I reported. But if you wait 5-10 seconds and then reload the preview page then it does display the edited content.

So as soup-bowl reported in #127171 - it's not completely broken. But in my view just broken enough to make it unusable.

davidAIS picture davidAIS on 12 Dec 2018
👍3

I am experiencing the exact same behavior as @davidAIS. I don't think this started right away after 5, maybe the 5.0.1 update did it. Refreshing the preview after a few seconds does indeed work.

xy0 picture xy0 on 13 Dec 2018

I am experiencing the exact same issue. I am using chrome, and windows 10. I set up a staging site, deactivated all plugins, and activated the default theme. I edit a page, that is published. Then I press preview and it does not show my edits. If I wait and refresh it will show my edits, or if I publish the post, it will also display my edits.

amycmcc picture amycmcc on 14 Dec 2018

I tested again with WordPress 5.0.1 and Gutenberg 4.7.0 master @ ddac4f3cf and with WordPress 5.0.1 and also with Gutenberg 4.7.0 today and previewing changes to published posts is always working in my tests. (1m14s)

Since more than one of you have mentioned you have tried testing with all plugins deactivated and using the default theme, there must be another factor we haven't thought of yet! If you spot anything I've missed in the latest testing video (linked above), please let me know.

Could a local firewall rule or caching server be interfering for you by chance?

What about browser extensions or add-ons, do you have any installed?

designsimply picture designsimply on 18 Dec 2018

Same issue here, on most of my sites. All sites are on the same server-- but at least one site doesn't show the problem. So it's not something tied to a server issue. Also, using Chrome on Windows 10 for all testing -- again, it does not seem to be a browser issue, because of the site without the problem. (And it consistent -- the one site that works, always works; the others I've tested always fail.)

I have tried disabling all plugins and reverting to TwentyNineteen theme on one site and it did NOT resolve the problem. Also, the sites with the problem have multiple different themes -- so it does not appear to be tied to a specific theme.

After reading comments here I did try a hard refresh (shift + refresh) while testing, and the changes in the preview do display that way .... so maybe a browser caching issue?

Edited to Add: I've now tested in Firefox and on guest window in Chrome (with addons disabled). Problem remains -- so it does not appear to be specific to a browser plugin or addon.

Armarsh picture Armarsh on 18 Dec 2018
👍1

It's very interesting that the issue is inconsistent based on environment. Defaulting the .htaccess didn't work. Neither did disabling my computer's firewall and hosts file. I've also tested on a default Chrome window without extensions.

I don't see any console errors or warnings. I'm not familiar with how WP creates previews, but could it be some sort of transient or DB delay? Does it use scripts? And could it be affected by a custom script order?

xy0 picture xy0 on 18 Dec 2018
👍1

You could be on to something there with the comment about transient or DB delay. I have about 10 sites on a shared VPS server -- and I have found only 2 sites that don't have this problem. Those 2 are very low traffic sites as compared to the others -- so it could definitely be something that is tied to database contents & load time. That would also explain why it might not show up in new, clean testing installations.

Edit to add: I took a look at the size of the database for each of my sites. The two sites that function well with previews have database sizes of 3M or under. Among the sites that are giving me problems, the smallest DB is 4.1M -- but most are larger. I wouldn't expect my particular values to hold true for other sites, as it would be a server-side issue that would also be tied to server load and resources. But at least this gives weight to the DB delay theory.

Armarsh picture Armarsh on 19 Dec 2018
👍1

I ran into this issue today. The problem is when you don't click out of the block you're editing before pressing the Preview button.

Pressing the Preview button should automatically save the block that your cursor is currently in, _then_ generate the preview.

scottbuscemi picture scottbuscemi on 20 Dec 2018

@designsimply Please let me know if you're able to repro with this new information ^

scottbuscemi picture scottbuscemi on 21 Dec 2018
❤1

I ran into this issue today. The problem is when you don't click out of the block you're editing before pressing the Preview button.

Pressing the Preview button should automatically save the block that your cursor is currently in, _then_ generate the preview.

This isn't new information. The essence of this bug report is that clicking Preview DOESN'T save the block changes (by which I assume you mean a temporary save) before creating the preview.

You seem to be suggesting in your first paragraph that clicking somewhere outside the block will temporarily save the block and is a necessary step before clicking Preview. Surely that can't be right!

davidAIS picture davidAIS on 21 Dec 2018

@davidAIS We're on the same page. I added clarification because this is still tagged as 'needs more info'. At this point, it should be updated as ready for patching...

scottbuscemi picture scottbuscemi on 21 Dec 2018

@scottbuscemi -- following your process -- clicking outside the block -- does NOT resolve the problem for me. No matter what I do, the preview page does not show the changes until the preview page is refreshed.

So no, while that may be a separate issue, that is not the core problem I am experiencing.

The only thing that works for me is to either revert to draft mode (which would take an active page on a live site offline) -- or to click the "update" button, which renders the preview function irrelevant. Or, as noted, either do a hard refresh of the preview page or a soft refresh after an interval of several seconds.

Armarsh picture Armarsh on 21 Dec 2018

I’m having the same experience as @Armarsh. We run wp 5.0.2 on a local apache server that’s offline (intranet). Theme is Generatepress. Never had this issue pre WP 5 (has been using Gutenberg since June or something).

slimmilkduds picture slimmilkduds on 21 Dec 2018

Hello,

I just wanted to add that this issue exists on wp.org. When adding a new paragraph to the Canadian Style Guide (https://en-ca.wordpress.org/style-guide/) and clicking preview the new paragraph block isn't displayed on the front-end.

It was mentioned in #meta that it seems to occur more often with existing content that was converted to blocks. As well .org has multiple databases and heavy caching so there can be a delay between saving content and having it appear back.

Slack convo w/ @Otto42 - https://wordpress.slack.com/archives/C02QB8GMM/p1545413856002200

Let me know if there's any architecture info required and I can get more info about the wp.org setup.

Thanks

garretthyder picture garretthyder on 21 Dec 2018
❤1

The problem is when you don't click out of the block you're editing before pressing the Preview
button.

@scottbuscemi I tested this with WordPress 5.0.2 and no active plugins using Firefox 63.0.3 on macOS 10.13.6 and found I was always able to see previews working. (38s)

I'm not familiar with how WP creates previews, but could it be some sort of transient or DB delay? Does it use scripts? And could it be affected by a custom script order?

@xy0 the conversation at https://wordpress.slack.com/messages/C02QB8GMM/ also mentions databases and heavy caching:

I would not be surprised to have it happen more on .org because of the fact that we use multiple databases and heavy caching, so there can be a delay between saving content and having it appear back on a reading of that content, but that delay tends towards the very small. I think the preview window tries to load a little bit too quickly. This may be a problem new to 5.0

@Armarsh, your experience that it happens for some sites and not others on the same server tested from various browsers is interesting. Is there anything at all you can think of that's different for the site configuration or settings for the one that is working properly compared to the others? What about the type of content—in the site that's working well, is the content consistently shorter or anything like that?

I'm labeling this as a bug and adding as high priority since several people have now reported it in multiple issues. I am also leaving the "needs more info" label in case someone can think of any additional similarities between your cases that will help narrow down the source of the problem. Thank you for focusing in on the details for this one!!

designsimply picture designsimply on 21 Dec 2018
❤1

As I wrote above, the difference is simply in the sizes of databases tied to each site. The ones that work have overall databases of less than 3meg, the ones that don't have databases of at least 4+ meg and many are much larger. There is nothing else I can put my finger on that would differentiate the sites, given that I've already ruled out theme or plugin conflicts with testing on the problem sites.

Of the two sites that function well, one site is very small -- just one of those basic 5-pagers that lists basic info and rarely updated. But another one is a rather complicated and extensive wiki-type site -- but it is for private use so not indexed by search engines which keeps site traffic to a minimum. Also it is mostly text-based -- very few images. But when I created new test pages with only a few lines of text on the problem sites -- the problem persists --so I don't really think it is tied to page content.

This doesn't happen with posts in draft mode -- I spent last night doing a lot of work on a new, still unpublished page with multiple shortcodes drawing from the database on one of the problem sites with a 22+ meg database, no problem at all. But as soon as a page is published, then the problem crops up.

So I do think it is tied to a difference in process between edits to a published page vs. draft -- coupled with database response time. Somewhere along the line there is an extra step that isn't being completed before the preview page initially renders.

Armarsh picture Armarsh on 22 Dec 2018
👍1

I had this issue with a draft on a large (gigabytes-big) database site.

scottbuscemi picture scottbuscemi on 22 Dec 2018

I can confirm on wp.org that drafts seem fine. It's when editing a published post/page that the issue with preview arises.

garretthyder picture garretthyder on 22 Dec 2018

If it helps at all - here is some system info for my sites:

MySQL 5.7
2 of the sites with problems are running PHP 7.1; all other sites (with & without problems) are running PHP 7.2.

Armarsh picture Armarsh on 22 Dec 2018

I am having the same issue, but in my case, Yoast SEO seemed to be causing it. When I deactivate the plugin, preview seems to work fine. If I use classic editor with yoast, the preview works fine. With block editor and yoast active, you can preview a brand new page, but as soon as you publish it, the preview does not show your changes. However, if you wait a few seconds, and refresh the preview page, the changes show.

hyptx picture hyptx on 27 Dec 2018

Has anyone notified Yoast?

scottbuscemi picture scottbuscemi on 27 Dec 2018

I did. They have a github page as well: https://github.com/Yoast/wordpress-seo/issues/11923

hyptx picture hyptx on 27 Dec 2018

Thanks, I tweeted at them which might bring more attention.

--

Scott Buscemi
On Dec 27, 2018, 10:43 AM -0800, Adam J Nowak notifications@github.com, wrote:

I did. They have a github page as well: Yoast/wordpress-seo#11923
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

scottbuscemi picture scottbuscemi on 27 Dec 2018

I just want to note that I’m not using Yoast and still have this issue

slimmilkduds picture slimmilkduds on 27 Dec 2018

Some of you seem to be jumping to conclusions pretty quickly, which isn't contributive to a proper assessment of the situation. Please only make statements about causes or solutions when they are determined through thorough technical examination and testing, and please don't call on 3rd party developers unless there is certainty about their needed involvement. Yoast has nothing to do with this issue.

litemotiv picture litemotiv on 28 Dec 2018

So I too noticed that the preview in the Gutenberg editor in Wordpress 5.0.2 is not working properly. I did some testing and noticed that once I published a post, a "Switch to Draft" link appears next to the "Preview" button:

switch-to-draft

As long as this link is there, any changes I did to the post's content did not show up in the preview.

However, once I clicked that link, the preview worked again.

As a side note: I have disabled the visual editor (because of a plugin I'm using). Maybe this has something to do with the behavior.

skrysmanski picture skrysmanski on 31 Dec 2018

After disabling Yoast I'm still having this issue.

Vixxd picture Vixxd on 7 Jan 2019

It is a strange bug, on another site of mine disabling yoast doesn't fix the issue. You need to refresh the preview after about 6-7 seconds to get it to show. Very tough to work in such a way.

hyptx picture hyptx on 7 Jan 2019
👍1

I tested and confirmed with WordPress 5.0.2 and Yoast SEO 9.3 that I cannot preview changes made to published posts only when the Yoast plugin is active.

I am closing this issue as a plugin conflict based on my own testing and @hyptx's comments here and report at https://github.com/Yoast/wordpress-seo/issues/11923.

For those of you experiencing the problem without Yoast installed, I wonder if another plugin has a similar conflict. Please test with all plugins deactivated and make sure to clear cache before re-testing. If you are still experiencing the problem after that, please reply back here with relevant details and I would be happy to re-open.

designsimply picture designsimply on 7 Jan 2019
👎2

This doesn't make any sense.

Just because Yoast may be one of the circumstances that triggers this bug doesn't mean that it's not a Gutenberg bug / sensitivity. Tickets should not be closed under such superfluous testing, at least the intrinsic cause should be determined first, which is not merely the existence of Yoast.

If Yoast decides to change something in it's plugin which causes Gutenberg to work again we still don't know anything about the other non-Yoast scenarios, and the process will have to be repeated all over again. All the while there is likely a single circumstance for all reported environments. It's nonsense to state that Gutenberg is only required to work properly on completely vanilla websites, it's core functions should remain as stable as possible under all circumstances.

I tested and confirmed with WordPress 5.0.2 and Yoast SEO 9.3 that I cannot preview changes made to existing posts only when the Yoast plugin is active.

I am closing this issue as a plugin conflict based on my own testing and @hyptx's comments here and report at Yoast/wordpress-seo#11923.

For those of you experiencing the problem without Yoast installed, I wonder if another plugin has a similar conflict. Please test with all plugins deactivated and make sure to clear cache before re-testing. If you are still experiencing the problem after that, please reply back here with relevant details and I would be happy to re-open.

litemotiv picture litemotiv on 7 Jan 2019
👍1

This is NOT a plugin problem and NOT a Yoast issue. It is a Wordpress 5.0/ Gutenberg issue.

I do not run Yoast on any of my sites and tested with all plugins disabled, using default theme, before reporting here.

I provided very detailed info above as did others and I am disappointed that this report is being closed as it is is an ongoing issue with Gutenberg that needs to be addressed.

Changing the TITLE of this report to reflect a plugin that I am not using doesn't solve the problem.

I'm opening a new report. I am very disappointed that this has been closed given the fact that most of the reports on this thread are NOT tied to Yoast or any other specific plugin.

I have opened this as issue #13232

Armarsh picture Armarsh on 8 Jan 2019

@litemotiv, solving cases where plugin conflicts are involved can be tricky. It's common to first look at the editor (or the current plugin) without the influence of other third-party code. Whether to close an issue or continue to ask for details can sometimes be a delicate balance, however, I have found that often times closing and allowing the issue to re-surface without _comments that include speculation_ can be helpful. I watch for those issues closely when I am working on triage. In this case, I tested several times and could not reproduce the problem and when I tested with Yoast SEO I immediately saw the problem happen and so I decided to defer to the open issue in the Yoast repository as a next step. If that turns out to be incorrect, we can re-visit! Preferably, for this case, I would like to see what comes out of the Yoast SEO report as well as watch for additional reports of problems with Previews here. I appreciate your concern and am listening. I'm sorry you feel the testing was superfluous, and I would like to politely and respectfully ask if you are experiencing the issue and if it would be possible for you to post a list of your active plugins. Based on the information I have seen so far on this issue, plugin conflicts do seem likely and it would be good to narrow them down and it is also possible there is something else triggering the problem or more than one bug at play and the more the issue is reported without bias the better I feel I will be able to get a handle on helping with it.

designsimply picture designsimply on 8 Jan 2019

@Armarsh please don't be disappointed. This may be a case where it is a plugin problem as well as something else. In your case, opening a new issue is a good route and I will have a look at the new issue you created.

designsimply picture designsimply on 8 Jan 2019

@designsimply -- does that mean that I should copy over all my detailed posts here into the new issue?

When I started posting here, there was no mention of Yoast. You added "Yoast" to the title when you closed it even though I and other posters here all indicated that we had tested with plugins disabled, using the default theme.

I feel that our input has been completely disregarded.

In my case there seems to be a correlation to the size of the site database-- so the issue as I described it would not be replicated on a new, clean installation, but would tend to show up on larger, more developed or high traffic sites. Of course that is only speculation as to the cause, but I can assure you that I RULED OUT any sort of plugin conflict before I posted here -- as did several others.

Armarsh picture Armarsh on 8 Jan 2019

I confirmed a plugin conflict in my own testing on a smaller site though. It appears the issue is not simple to sort out and there may be more than one trigger for the problem. You do not need to copy over everything from here to the new post, but including the part about the database size is definitely a pertinent detail and I added it in a comment already. I really think separating your report into a new one as you have done is a good route for this case!

designsimply picture designsimply on 8 Jan 2019

I tested on two separate sites a few minutes ago, both were not showing previews:

[site 1]
Active plugins: ACF Pro
After disabling ACF Pro previews started working

[site 2]
Active plugins: ACF Pro, Contact Form 7, Admin Menu Editor, Imsanity
After disabling ACF Pro previews still not working (haven't disabled the other plugins)

So it appears that it's not a matter of disabling a specific plugin such as Yoast or ACF Pro, which are some of the most used / relied on plugins on the planet obviously.

litemotiv picture litemotiv on 8 Jan 2019
❤3

Thanks @litemotiv. That is super helpful. I will see what I can find out from those plugin authors and the developers here and I may re-open this issue (or I may create a new one) once I find out more.

designsimply picture designsimply on 8 Jan 2019

@litemotiv Does it start working again when you disable the rest of the plugins?

scottbuscemi picture scottbuscemi on 8 Jan 2019

@scottbuscemi Yes, it appears so.

This is merely speculating at this point - which is dangerous obviously - but it's possible that there might be some sort of race condition happening when multiple sources are trying to call or hijack the autosave timer / hook.

litemotiv picture litemotiv on 8 Jan 2019

It's okay to speculate! However, sometimes it's helpful to separate out known issues (the plugin conflicts in this case) from other speculation (the race condition due to either a large database or too many calls by different plugins on the same resource). Thanks so much for testing and continuing to add detail!

designsimply picture designsimply on 8 Jan 2019

Reopening this issue with a note to explore whether plugins using metaboxes are the common factor and leaving #13232 open to explore the database size angle.

designsimply picture designsimply on 8 Jan 2019

Given that it has already been established by several people including myself that the issue persists even with all plugs disabled and with default themes, further exploration of plugin related issues seems unlikely to be productive.

I've never had this issue with previews when using the classic editor either with WordPress 5 or with previous versions of WordPress.

It therefore seems pertinent to ask what is different about the preview function with the block editor compared to the classic error which must surely be the place to start with this issue.

If the block editor has to carry out additional processing in order to generate the preview that the classic editor doesn't, then perhaps it would be useful to look at why the block editor fails to complete that processing before attempting to display the preview.

It has been widely reported here that if the preview is refreshed after 5-10 seconds then it is re-displayed correctly.

Perhaps the block editor isn't waiting long enough before it displays the preview or it's not being correctly notified that the processing has been completed and the preview is ready to be viewed and is displaying the preview prematurely.

If that is the case, although it might lead to a fix, it may also present further usability issues as the preview process is already quite slow and adding a further 5-10 seconds would make it even more so.

davidAIS picture davidAIS on 8 Jan 2019
👍2

I am troubled with the same problem.
I report my situation in hopes of leading to problem solving.

Gutenberg's preview does not work well under certain conditions.

If you make changes to published articles and preview them,
Changes will not be reflected in the preview screen, and will be displayed in the state before editing.
When you click on the Publish button, the changes are reflected both in the preview and the article.

The background to the problem is as follows.

  1. I installed Gutenberg plugin in Wordpress 4.9.8 and tested Gutenberg
  2. Updated to Wordpress 5.0.2
  3. Deactivated Gutenberg plugin, and confirmed there was no problem with the Gutenberg editor
  4. Deleted Gutenberg plugin
  5. This problem occurred

Before deleting the Gutenberg plugin, Gutenberg also worked preview without any problems.
Also, it does not mean that the preview does not work at all even after problems occur.

In draft postings with new posts preview works without problems.
Also, preview works if you change published to draft.
If you make it published, changes are not reflected in the preview.

Using the Classic Editor, Preview works regardless of published or drafts.

I do not use Yoast.
Try disabling all plugins, change to a different theme,
I tried reinstalling "Gutenberg plug-in" that triggered the problem,
It was not improved.
I tried the above procedure in a different environment, but I could not reproduce the problem.

toratiger picture toratiger on 9 Jan 2019
👍2

While there might be many ways for this behavior to occur, I've observed it happening with this combination involving PHP meta boxes:

  1. A published post is previewed, generating an autosave.
  2. The POST request to save PHP meta boxes is sent to post.php. The published post is updated and its last-modified time is bumped.
  3. The POST request is redirected as a GET request to post.php again. This logic runs, which compares the modified dates of the autosave and the post: https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-blocks.php#L294-L303
  4. The modified date of the post is now more recent than the autosave, so the autosave is deleted.
  5. The preview loads, but there's no more autosave to preview.
dlh01 picture dlh01 on 9 Jan 2019
👍2

The preview functionality works by the post-preview-button component having a call to componentDidUpdate() that basically attempts to load the preview URL in the preview window every time the component is re-rendered. It stops if there is no preview link or preview window available.

So when you click the preview button this is essentially what happens:

1) It checks to see if a preview window already exists, if not (or has been closed), it opens a new tab/window for the preview
2) It focuses on the preview window (which means the rest of this occurs in the background since your browser now has the preview window focused)
3) It checks to see if the post can be autosaved using isEditedPostAutoSaveable() and if it can't be autosaved, then it just opens the URL in the href attribute of the preview button and stops.
4) If we've reached this point, autosave is possible most likely because there are edits. But first it looks to see if it's a draft, and if so, it just does a regular save.
5) If it's not a draft, then it triggers an autosave because we don't want to update live content yet.
6) Both the autosave and the regular save have the same effect of causing the component to re-render, which triggers the componentDidUpdate() and forces the preview window to reload.

Seems like there are a couple of opportunities for race conditions here due to the various moving parts required to determine when to load the preview and what URL to load. I need to do some more testing to see where I can get this to fail.

earnjam picture earnjam on 9 Jan 2019
❤1 👍1

I have experienced this issue with every page on sites that upgraded to 5.0. Any page that was created before the update does not show changes in the preview, or after publishing. Converting the page to blocks does not seem to resolve the issue.

KristaButler picture KristaButler on 10 Jan 2019

I have this problem on 10 different sites with 8 different themes --- and the one thing that every site shares is that this started with the WP 5.0/ Gutenberg upgrade. So I think that's the heart of the problem, one way or another. And again, disabling plugins and reverting to Twentynineteen didn't solve the problem on the sites that I tested.

Armarsh picture Armarsh on 10 Jan 2019

I have done some additional testing but am still looking for reliable steps to reproduce the problem that does not involve plugins.

Based on the information in https://github.com/WordPress/gutenberg/issues/12617#issuecomment-449520938 I ran the following test:

  1. Go to https://jurassic.ninja/ and create a new test site.
  2. Go to Plugins > Add New, search for FakerPress, install & activate.
  3. Go to FakerPress > Posts and generate 200 posts and 80 pages.
  4. Check the size of the database using wp db size --size_format=kb via wp-cli (ssh credentials for jurassic.ninja sites are provided in an admin notice).
  5. Go to Posts and open any published post.
  6. Make any edit to the post.
  7. Click the "Preview" button and check to see if the edit appears in the preview.

Result: the database including the sample content was 5.8 MB and all previews still worked normally in my own testing. (1m38s)

Continuing on, I decided to also test Yoast SEO again since they had recently updated to version 9.4.

  1. Go to Plugins and install or update to Yoast SEO 9.4.
  2. Go to Posts and open any published post.
  3. Make any edit to the post.
  4. Click the "Preview" button and check to see if the edit appears in the preview.

Result: previews of edits made to published posts do not appear if Yoast SEO 9.4 is installed and activated. (53s)

Last, I tested Advanced Custom Fields since it was mentioned as problematic in earlier comments.

  1. Go to Plugins and install or update to Advanced Custom Fields 5.7.9.
  2. Go to Posts and open any published post.
  3. Make any edit to the post.
  4. Click the "Preview" button and check to see if the edit appears in the preview.

Result: previews of edits made to published posts do not appear when using Advanced Custom Fields 5.7.9. (1m23s)

What I'm seeing in testing so far is that I can definitely correlate some plugins, particularly plugins using meta boxes, with the problem but I am not sure if they are the cause. I can also say that I do not personally see the problem for a site with a database that is 5.8 MB. For those of you having trouble even after deactivating all plugins and switching to the default theme, I am not sure yet what is causing the trouble in your case. @earnjam, if you have any ideas for what else to test, please let me know so I can help out!

designsimply picture designsimply on 12 Jan 2019

@KristaSnapdragon I noticed you mentioned the problem happens for you on pages created before updating to WP 5.0. May I ask if the same problem happens for you on posts you create _after_ updating to WP 5.0?

designsimply picture designsimply on 12 Jan 2019

I'm testing on a site that was created prior to WP 5.0 and the block editor but now with all plugins except Classic Editor deactivated and using the 2019 theme.

In that configuration I am consistently seeing the reported issue with edits to existing pages when edited with the block editor. That's also the case if I turn off the Classic Editor plugin.

In other words there is no interaction here with Yoast or any other plugin in the case of content created prior to WP5.0 and the block editor.

If the Classic Editor is turned off the I can create new content and edit content created using the block editor and preview works correctly.

But if the Classic Editor plugin is turned on, then the issue appears when editing new content that has been created after Classic Editor was turned on - even if it was created with the block editor

It might be tempting to conclude that the issue is a clash with the Classic Plugin itself. However the fact that the issue occurs for content created prior to WP5 and the block editor when it is subsequently edited with the block editor and when there are no activated plugins demonstrates otherwise. There is something more fundamental going on!

davidAIS picture davidAIS on 12 Jan 2019

While there might be many ways for this behavior to occur, I've observed it happening with this combination involving PHP meta boxes:

  1. A published post is previewed, generating an autosave.
  2. The POST request to save PHP meta boxes is sent to post.php. The published post is updated and it's last-modified time is bumped.
  3. The POST request is redirected as a GET request to post.php again. This logic runs, which compares the modified dates of the autosave and the post: https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-blocks.php#L294-L303
  4. The modified date of the post is now more recent than the autosave, so the autosave is deleted.
  5. The preview loads, but there's no more autosave to preview.

@dlh01 Thanks for debugging that. I think that's the clearest explanation of what's happening here. 👍

talldan picture talldan on 14 Jan 2019

@talldan There are also people reporting it without any meta boxes though, so I don't think that's the only culprit.

earnjam picture earnjam on 14 Jan 2019

@earnjam Yep, but I don't want a very good explanation of one of the causes to be buried in this thread.

talldan picture talldan on 15 Jan 2019
👍4

Not much to add except I am having the same issue with both Yoast and ACF on a vanilla WP using Twenty-Nineteen.

  • Preview works as expected when page is unpublished.
  • If page IS published, then further changes made via Gutenberg blocks are not shown when previewing. I have to unpublish the page for preview to begin working again.
  • Disabling Yoast/ACF resolves the problem.

Disabling Gutenberg/installing Classic Editor allows Preview to work as expected.

Using PHP 7.2.9 and MySQL 5.7

jweston491 picture jweston491 on 16 Jan 2019

I have the problem as well.

  1. Post created with classic editor and published
  2. Trying to edit with Gutenberg
  3. Preview is not displaying the changes
bhagwad picture bhagwad on 16 Jan 2019

I have the problem as well but not like the others who posted here my wordpress version is not yet updated to 5. Even refreshing the preview page is not working for me.

nicosabio2016 picture nicosabio2016 on 17 Jan 2019

@nicosabio2016 thank you for the note! Would you mind noting a bit more detail about your setup for reference? For example, exact WordPress version, Gutenberg plugin version, whether you've tried testing with all plugins temporarily turned off, and how long the problem has been happening to you (if you can remember!).

@bhagwad it would be great if you could include some extra details such as your WP version and whether you have tested with no plugins active. Thank you!

@jweston491 thanks for confirming that the problem only happens for you when previewing edits to published posts and only if you have either ACF or Yoast plugins activated.

designsimply picture designsimply on 17 Jan 2019

Same problem for me with 5.0.3 hosted on IIS, the preview does not reflect the changes made in a page. The problem arose when I updated from 4.9.4 to 5.0.3. Is there any solution for this?

johnnyontheweb picture johnnyontheweb on 18 Jan 2019

While there might be many ways for this behavior to occur, I've observed it happening with this combination involving PHP meta boxes:

  1. A published post is previewed, generating an autosave.
  2. The POST request to save PHP meta boxes is sent to post.php. The published post is updated and it's last-modified time is bumped.
  3. The POST request is redirected as a GET request to post.php again. This logic runs, which compares the modified dates of the autosave and the post: https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-blocks.php#L294-L303
  4. The modified date of the post is now more recent than the autosave, so the autosave is deleted.
  5. The preview loads, but there's no more autosave to preview.

We've tested this hypothesis with the Yoast SEO plugin, and it seems @dlh01 is right.

When clicking the preview button, there are two autosaves triggered: one of the post itself, and one of the Yoast metabox. The autosave of the post has a timestamp that is one second before the autosave of the metabox. This means that after the above mentioned compare between the dates, the autosave of the post is deleted, while the autosave of the metabox is the one that is used for the preview.

Because the metabox autosave doesn't contain the post content, (our hypothesis is that) it uses the content of the original save, which means the latest changes (that were in the deleted autosave) do not show up in the preview.

For testing purposes, we changed > to < in https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-blocks.php#L296. In that scenario, it keeps the autosave from the content, which means the preview is up-to-date.

When we disable the yoast metabox (but keep the plugin active) the problems disappear and the preview is up-to-date as well.

IreneStr picture IreneStr on 22 Jan 2019
👍6

Thank you for testing and leaving a comment with findings @IreneStr!

I took a moment today to re-test with the latest development versions WordPress 5.0.4-alpha-44523 and Gutenberg 4.9.0-rc.1 and Yoast SEO 9.5 (and without Yoast SEO) using a https://jurassic.ninja/ test site and found that I am still unable to preview edits to published posts.

designsimply picture designsimply on 23 Jan 2019

@IreneStr & @dlh01 That's great, thanks for validating this cause.

The modified date of the post is now more recent than the autosave, so the autosave is deleted.

I have an idea for a pretty simple fix for this, which is not to delete the autosave if the request is for a meta_box update. Change it from:

    } else {
            wp_delete_post_revision( $autosave->ID );
    }

to:

    } elseif ( ! isset( $_REQUEST['meta_box'] ) ) {
        wp_delete_post_revision( $autosave->ID );
    }

It seemed to solve the issue when I tested it, but I'm not completely familiar with the code for updating metaboxes. Maybe there's a better solution.

talldan picture talldan on 23 Jan 2019

@talldan I think since we are triggering two save requests (post api and metabox) when we have metaboxes, I think the idea was to explicitely delete of the revisions. So probably instead of deleting the metabox autosave, we should overwrite the previous one. What do you think?

youknowriad picture youknowriad on 23 Jan 2019

@talldan I'm not sure I'm familiar enough with all the intentions of edit-form-blocks.php to offer a really informed opinion about adding a $_REQUEST check in that location. I imagine that it would address the immediate problem, though.

But the current logic of deleting the revision, in itself, also seems sound. The request to save PHP meta boxes results in a "true" update of the post via wp_update_post(), not another autosave. In all other cases core would (I think?) expect that the existing older autosave would be deleted at the next opportunity. See the similar logic in edit-form-advanced.php: https://github.com/WordPress/wordpress-develop/blob/e5b5db9e2349dfe8a43ac42bea5738146f53994d/src/wp-admin/edit-form-advanced.php#L226-L239.

So creating a scenario where an autosave exists when core doesn't expect one to exist could have side-effects.

Again, though, I could be wrong on the facts, and the risk involved in adding an exception might be minimal regardless.

dlh01 picture dlh01 on 24 Jan 2019

So probably instead of deleting the metabox autosave, we should overwrite the previous one. What do you think?

@youknowriad So you mean overwrite/update any existing autosave during the secondary meta box update? That would improve the situation, as you'd no longer have a lingering autosave that's older than the post, which seems to be the case this code is trying to avoid.

But the current logic of deleting the revision, in itself, also seems sound. The request to save PHP meta boxes results in a "true" update of the post via wp_update_post(), not another autosave. In all other cases core would (I think?) expect that the existing older autosave would be deleted at the next opportunity.

@dlh01 Yep. I think the way Gutenberg handles metabox updates is definitely an edge case. You're right in that it's probably a good idea to stick to that core rule of having autosaves that are older than the post not be retained.

The other solution that came to mind is to change the order of the updates when previewing:

  1. Update post meta
  2. Autosave the post
  3. Show the preview

It would most likely involve some less than ideal code in gutenberg, as the post meta save is currently triggered as a side-effect using a subscription:
https://github.com/WordPress/gutenberg/blob/0259f7b2aec9ab66f3a040d08a5aeeb5c65e5756/packages/edit-post/src/store/effects.js#L50-L72

talldan picture talldan on 24 Jan 2019

I'm having a very similar issue, however the changes appear if I wait 5 seconds after the preview loads, then hit reload.

bonlando picture bonlando on 29 Jan 2019
👍1

There is also a report from @dariaknl which might need some action here:

@gziolo I have looked into this issue (#13038) using wordpress-seo plugin (with e2e tests). Your test is failing with:

    Expected: "Hello World! And more."
    Received: "Hello World!"

      107 |       // Title in preview should match updated input.
      108 |       previewTitle = await previewPage.$eval( '.entry-title', ( node ) => node.textContent );
    > 109 |       expect( previewTitle ).toBe( 'Hello World! And more.' );
  • once the post has been published it does not get updated title in preview if you change the title.
    Indeed the test succeeds with wordpress-seo disabled.

But I tried the same test with built-in Advanced Panels “Custom Fields” enabled and wordpress-seo disabled. I get the same result - the test fails, updated title is not shown in preview. So it seems that the issue is related more to the problem with metabox in general.

I tested with: WP 5.0.3 and Gutenberg 4.8.0 and 4.9.0.

gziolo picture gziolo on 30 Jan 2019

Did some digging on this. In my testing, the deletion of the autosave didn't seem to matter either way.

The issue stems from a couple of criteria:
1) On published posts, we just want to trigger an autosave and not a regular save on preview because we don't want to update the actual published content yet.
2) Post meta doesn't support revisions, so it has to do a standard save and update immediately.

Metabox saves are handled by a POST to /wp-admin/post.php. That triggers a call to edit_post() and eventually wp_update_post(), which will always update the post_modified date of a published post. Since the meta box save request comes after the autosave request, the post_modified date is newer by 1 second on the published post than on the autosave that is created. The preview sees that and just loads the published post, since it's newer.

We need the post_modified date of the autosave to >= the published post. Flipping the order in which the two separate calls are made seems like the logical solution if it's possible.

earnjam picture earnjam on 30 Jan 2019

I revisited this today to test out reordering the two requests on a preview, and I now see it deleting the autosave. (I think I was looking at the wp_delete_post_revision() call in core, but had the Gutenberg plugin active, which overrides the editor screen and has it's own call of that function)

It also doesn't matter to the preview whether the autosave post_modified is older or newer than the actual post (I tested by directly changing it). Preview shows the autosave post_content if it exists at all. So the issue is indeed related to the autosave being deleted.

So pretty much ignore my whole post above this one ¯\_(ツ)_/¯ 😀

I tried removing the metabox save subscription on previews, and then directly calling it from the preview button before the autosave request to see if that would be enough, but it's still a race condition situation that often ends with the autosave being deleted because it's usually a good bit faster to execute than the metabox save.

Seems like we either have to wait on the response from the metabox save before triggering the autosave, making them even slower than they already are, or else put in some kind of exception to the removal of the autosave like @talldan mentioned above. Both seem...not great.

earnjam picture earnjam on 31 Jan 2019

@earnjam Thanks for looking into it. I agree, I'm not enthused about any proposed solution so far.

Any thoughts on what the best option is?

Also should mention there are a couple of trac tickets covering this as well with discussions:
https://core.trac.wordpress.org/ticket/45768
https://core.trac.wordpress.org/ticket/45532

talldan picture talldan on 1 Feb 2019

Interesting. I just experienced this for the first time today editing an old post from 2011, which it placed in a complete Classic Block. I added a paragraph block above it and removed a link from within the Classic Block. Clicked Preview and it showed what I had before any edits with no changes. I tried clicking around different sections and it made no difference. So, I just clicked Update and then the Preview showed the correct content.

Anyway, I'm on WP 5.0.3, Twenty Twelve child theme, and using Firefox 65.

Just tested again and like what some other have said, if I wait a few seconds and refresh the tab that has the preview in it, I then see the changes. So, some odd timing issues.

It's been quite some time since I've edited old post so I'm not sure how far back it would have started.

MarkRH picture MarkRH on 7 Feb 2019

Apologies for the delay on the fix for this—it's a challenging issue. I now have a proposed fix at #13718.

talldan picture talldan on 7 Feb 2019
❤1

I do not know if it can help, but I noticed the following:

  • it only happens on specific existing pages (created new ones and the bug was not present)
  • for the pages where the bug shows up, the browser only loads the page once
  • for the pages where the bug is NOT present, the browser loads the page content twice. (This is actually not very clean of a design, even in the cases where it "works". You can see the current published content show up a fraction of a second... then the page goes blank, the browser initiate a second load and the current non saved draft edits show up finally).

So can we assume that it is related to some states related to a given page post within the SQL DB, which are used in the preview button logic? Those states being also linked to the autosave logic seems a safe bet indeed.

The whole preview logic should maybe be rewritten from the ground up... I've tracked issues related to this back from 2013 or so, on pretty old WordPress releases. It's been a rampant bug for quite a while it seems.

If possible, the double load trick should be replaced by a cleaner logic that only loads once, even if it's a non published content version.

Regards.

marcber picture marcber on 16 Feb 2019

I've also just noticed this happening; none of the edits from the admin view (code/css) are appearing ont he preview instance.

thetroublemaker picture thetroublemaker on 22 Feb 2019

Quick note: this problem seems to have gotten worse with WP 5.1 update.

Before: Preview would not appear initially, but was viewable a few seconds later with a refresh of the preview page.

Now: Preview does not appear at all. Options are to either update the published page to see changes, or revert the published page to draft status while completing edits.

Armarsh picture Armarsh on 22 Feb 2019

Yeah, I can confirm. With 5.1, editing an existing post, preview will not show any changes. Refreshing the preview page no longer works for me as well. So, yeah, it has gotten worse. (Firefox 65.0.1 in Windows 7)

I also does not work if I edit a post I just created in 5.1.

Preview has worked just fine as I am making a post but have not published it yet.

MarkRH picture MarkRH on 23 Feb 2019

Same issue here, works with drafts though, with published not.

katsar0v picture katsar0v on 25 Feb 2019

I adjusted the title to reflect the specific details identified in this issue as the culprit. That will help us distinguish it from #13232 if there is another situation where metaboxes are not the cause.

earnjam picture earnjam on 27 Feb 2019

I've had the PREVIEW BUTTON _do nothing_ on more than one website, even with WP5.1 and it is painful.

it-tbt picture it-tbt on 2 Mar 2019

Hi all - Long time listener, first time caller! I love the new block editor and really appreciate the work you all do.

I've been looking into this for a bit because we have a lot of client sites that we've upgraded and we use meta-boxes extensively. I'm not a react developer so I'm sorry if this comment is unhelpful. However, I'd really love for preview to work so I thought maybe these ideas might be helpful. Also, I'm only working off of the build files currently bundled into 5.1 so I don't know if my suggestions here will necessarily work.

To me, this looks like an order of operations problem. I can see that when autosave is triggered, there is a listener in the edit-post component that is like "hey did we just do an autosave? do we have meta boxes? we do? lets update those boxes." (I can see this happening in lines 46 - 72 of edit-post/src/store/effects.js) and then the update requested by the edit-post component is overriding the state and thus the preview generated is not for the latest autosave. If I comment out the subscriber in those lines in my build file, the preview works just fine (however, i have no idea of the implications that result in previewing changes to metaboxes).

It seems to me that it should be the editor component that first broadcasts to the edit-post component that it is about to process an autosave, that way the edit-post component can request it's updates, then the editor component can process the autosave and the thus preview will be the latest autosave. Although, off hand I don't know the right way of doing this so I'm not sure what this might look like.

However, I was also able to get it to work by dispatching a new autosave inside the chained callback in line 117 of the file listed above, effect.js. By invoking a new autosave directly like so: dispatch('core/editor').autosave(). Perhaps that's another hacky solution. So my edit looks like this:

// starting on line 111
apiFetch( {
            url: window._wpMetaBoxUrl,
            method: 'POST',
            body: formData,
            parse: false,
        } )
            .then( () =>{ 
                              // invoke new autosave - maybe add some more conditional logic here to figure out
                             // what triggered this request so that if it's a full save, we request a save, or if it's an
                             // autosave we do an autosave like so.
                              dipatch('core/editor').autosave();
                              store.dispatch( metaBoxUpdatesSuccess() ) 
                        });
DimeZilla picture DimeZilla on 7 Mar 2019

Preview is not working for me in 5.1. I waited for 5.1 to try Gutenberg assuming it would work properly by this point... how can I edit my (pre published) posts and see a preview? This is the most basic thing I can think of. I have to press update each time at the moment.

The actual preview inside Gutenberg does not reflect how it appears on the published post, the formatting of the text in relation to the images is different.

I would actually really like Gutenberg if it worked :)

David-Else picture David-Else on 9 Mar 2019

Preview is not working for me in 5.1. I waited for 5.1 to try Gutenberg assuming it would work properly by this point... how can I edit my (pre published) posts and see a preview? This is the most basic thing I can think of. I have to press update each time at the moment.

The actual preview inside Gutenberg does not reflect how it appears on the published post, the formatting of the text in relation to the images is different.

I would actually really like Gutenberg if it worked :)

I'm in the same boat over here. I thought it would be stable by now but my preview in 5.1 literally never works. :(

Running WP 5.1 on Google Cloud Compute Engine (Click to Deploy)

jaydanurwin picture jaydanurwin on 10 Mar 2019

On 5.0.3, preview doesn't work. Trying to refresh or empty caches on the preview page doesn't change anything.

kaylegh picture kaylegh on 11 Mar 2019

As mentioned on the other issue (https://github.com/WordPress/gutenberg/issues/13232), this now seems to be resolved. I'm not sure which particular change has resulted in the fix.

talldan picture talldan on 15 Mar 2019

Nope. Not fixed in 5.1.1. Editing an existing post and clicking preview does not show the changes.

MarkRH picture MarkRH on 15 Mar 2019
👍1

@talldan After testing few themes, I noticed that this problems occurs in those theme which has custom meta fields for the page. In those theme which has no custom meta box, preview works as expected.

ernilambar picture ernilambar on 15 Mar 2019
👍1

Most data-driven WP sites use some form of custom fields, our site as an
example uses ACF.

On Fri, Mar 15, 2019 at 2:23 AM Nilambar Sharma notifications@github.com
wrote:

@talldan https://github.com/talldan After testing few themes, I noticed
that this problems occurs in those theme which has custom meta fields for
the page. In those theme which has no custom meta box, preview works as
expected.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/WordPress/gutenberg/issues/12617#issuecomment-473172823,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADUrkUAGtSmWGiDRvdyUbSVPhCymk6s_ks5vWzxKgaJpZM4ZC_rC
.

thetroublemaker picture thetroublemaker on 15 Mar 2019

Lack of preview persists on my sites with WP 5.1.1.

Armarsh picture Armarsh on 15 Mar 2019
👍3

@ernilambar I tested using a custom field, which has the same effect.

@Armarsh, @MarkRH - I tested against master, and I couldn't reproduce. If this is fixed, there's a chance the fix hasn't been released yet.

talldan picture talldan on 15 Mar 2019

Most data-driven WP sites use some form of custom fields, our site as an example uses ACF.
…
On Fri, Mar 15, 2019 at 2:23 AM Nilambar Sharma @.*> wrote: @talldan https://github.com/talldan After testing few themes, I noticed that this problems occurs in those theme which has custom meta fields for the page. In those theme which has no custom meta box, preview works as expected. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#12617 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/ADUrkUAGtSmWGiDRvdyUbSVPhCymk6s_ks5vWzxKgaJpZM4ZC_rC .

After some testing I can confirm that this was the issue my site was having. Any themes/plugins that adds a meta box to the page editor will cause the preview button to not work. I removed anything that added a meta box from 5 different WordPress installs and the preview button is now working again.

Hopefully this issue will be fixed in the future but a quick fix would be to install the classic editor plugin.

Tintedshadows picture Tintedshadows on 15 Mar 2019

Lack of preview persists on my sites with WP 5.1.1.

Same, using Opera v. 60.0.3254.0 on Windows 10 and v. 58.0.3135.107 on Mac OS X 10.14.3

MoreFallout4 picture MoreFallout4 on 17 Mar 2019

After testing again, it looks like the problem still exists 😞

Sorry to get everyone's hopes up.

talldan picture talldan on 18 Mar 2019

+1, My combination Windows 10 + chrome Version 72.0.3626.121

gnanasekaranl picture gnanasekaranl on 20 Mar 2019

+1, can confirm we are experiencing the same issues Windows 10 and Chrome 72.0.3626.121

minderoodigital picture minderoodigital on 21 Mar 2019

Same problem here with 5.1. I discovered that it's not that Preview isn't populating the space, but that the font is defaulting to white - i.e. white-on-white. (Also Arial 50, which isn't what I want.) I can change the font color on my form, but not size or style. In my case, it might be fixable in our theme, but I'm just a WordPress end-user, not a developer (who is 8 time zones away so not reachable to fix this now.)

siobhan4587 picture siobhan4587 on 21 Mar 2019

+1, as almost all professional WordPress sites use some sort of custom meta field system - this is affecting nearly every site running Gutenberg currently.

JoshuaVB picture JoshuaVB on 26 Mar 2019

Still happening on 5.1.1. I upgraded from 4.x to 5.1.1 today. After adjusting to the new editor, I run into this problem. Hope there will be a fix in the near future.

fr0der1c picture fr0der1c on 26 Mar 2019

Now Gutenberg is completely not working. Earlier, I got around the no preview issue by duplicating the page, and switching it to draft. Now, any new post created with the new block editor renames the title to "Auto-Draft" and will not save. Creating posts is working normally with the Classic Editor plugin, but when I try to edit them with Gutenberg, they will not save or preview at all.

This issue has now become so bad that I have completely disabled Gutenberg -- obviously, because it can't save anything.

xy0 picture xy0 on 27 Mar 2019

I don't have any problem with creating new pages with Gutenburg -- just the preview issue with already published pages. How are you duplicating the page? It sounds to me that you may be using a plugin to create the duplicate, and that is what is giving you the "auto-draft" title --- and perhaps the problem with saving is tied to the plugin??? Have you tried simply creating a new page from scratch?

Armarsh picture Armarsh on 28 Mar 2019

I can still reproduce this issue with WordPress 5.1.1 and the Gutenberg plugin version 5.4

Test procedure:

  1. disable all plugins
  2. check that _Custom Fields_ are disabled in the block editor options
  3. make some changes in a post, click on _Preview_ and see that your changes are displayed
  4. enable _Custom Fields_ in the block editor options
  5. make some changes in a post, click on _Preview_ and see that your changes are not displayed
benoitchantre picture benoitchantre on 3 Apr 2019
👍3

This bug manifests itself every time I edit and wish to preview an already published post. The edits are never previewed. (Windows 7, Opera, latest WordPress version with "built-in" Gutenberg, ie not installed as a plugin)

I think this is a rather critical error.

vesaraiskila picture vesaraiskila on 5 Apr 2019

I fixed my website in the following way.

  1. not change post_modified_gmt if REQUEST_META_BOX_UPDATES action
add_filter( 'wp_insert_post_data', function ( $data ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        unset( $data["post_modified"] );
        unset( $data["post_modified_gmt"] );
    }

    return $data;
} );

or

  1. set autosave's post_modified_gmt = original post's post_modified_gmt +1 sec
add_action( 'save_post', function ( $post_id, $post ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        $autosave = wp_get_post_autosave( $post_id, get_current_user_id() );
        if ( $autosave ) {
            $filter = function ( $data ) use ( &$filter, $post ) {
                remove_filter( 'wp_insert_post_data', $filter );
                $data["post_modified"]     = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified ) + 1 );
                $data["post_modified_gmt"] = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified_gmt ) + 1 );

                return $data;
            };
            add_filter( 'wp_insert_post_data', $filter );
            wp_update_post( $autosave );
        }
    }
}, 10, 2 );
technote-space picture technote-space on 6 Apr 2019
👍6 🚀2

Thank you for sharing your solution, @technote-space! However, I don't think it should be up to us individual web hosts (the large majority of whom are not programmers and simply want to use a functioning user interface) to fix well-known bugs in the system.

vesaraiskila picture vesaraiskila on 6 Apr 2019
👍1

@technote-space - thank you for these suggestions. I'll try them out on some of my sites and see if they also work for me.

@vesaraiskila --I agree with you that we shouldn't need to use changes to functions in order to address bugs--- but sometimes it can take a long time before the bugs are ironed out. So it's helpful for many of us to have an interim solution. If it works, a filter that can be added to the functions.php file is a simple & easy-to-implement fix -- and it can also provide useful info for debugging to fix the underlying code.

Armarsh picture Armarsh on 6 Apr 2019
👍1

@technote-space -- I have tested each of your functions on different sites running Generate Press, and I can confirm that it works to resolve the preview issue.

One possible glitch -- on one of my sites I have last modified dates set to display on the post itself, and also tied to a "recent updated posts" widget. I found that the #2 option had the unintended side effect of adding a new last-modified date even if I did not save and publish the modification . (In this case because I was testing only ). I didn't find any problem with using the #1 option instead -- so that is the option I'll stick with on my sites.

Armarsh picture Armarsh on 7 Apr 2019
👍1

I am looking forwards for this issue to be solved in the core and be merged! Thanks guys!

katsar0v picture katsar0v on 8 Apr 2019
🎉1

This 'no real preview' is a big turnoff to new users.

I suspect many have decided against Gutenberg because they don't see this simple and first check of editing as working, and have thus elected to wait for a later version. It puts a taint on the whole project.

Remember when Google Drive first came out? A great flaw there was similar in that they automatically 'converted' uploaded Word docs (etc.) to Google Docs, and so very often they looked horrible. And if you tried to edit a Google Doc live in a meeting presentation, even the cursor would not stay in the right spot.

Similarly this was a real turnoff for Google adaption, all of which they have corrected. Hopefully soon this basic Gutenberg preview issue will become a thing of the past.

it-tbt picture it-tbt on 8 Apr 2019

This issue is occurring only when the post is published or page editor screen has metaboxes. In my case Yoast plugin.
Switch to Draft on the published page show the preview but that is not a solution for this.

harmancheema93 picture harmancheema93 on 3 May 2019

@harmancheema93 have you tested this with the latest version of the Gutenberg plugin, or with the WordPress 5.2 release candidate?

The fix for this has been merged, but will not be released in WordPress core until 5.2 comes out next week.

earnjam picture earnjam on 3 May 2019

In case this is helpful to anyone, updating to WordPress 5.2.1 fixed this issue for us.

jg314 picture jg314 on 30 May 2019
🎉4

We are still having the issue, just going to add my bit as slightly weird toggling thing going on where it toggles the content on and off, but long and short is that preview is not working for published pages using advanced custom fields, but is working for draft pages:

Using:

  • Advanced Custom Fields Pro 5.8.1
  • WordPress 5.2.1

Steps:

  1. Clicking preview on a published page will show no content (content is in ACF, no WordPress default blocks used), header and footer does show.
  2. Clicking preview again will bring the content from ACF this time but without content changes.
  3. Clicking preview again will then show the page to have no content. Like it toggles the ACF content on and off.

Checked that the URL is same (?preview_id=27&preview_nonce=abd991463b&preview=true) and is.

It works fine for pages in draft mode.

altescape picture altescape on 4 Jun 2019
👍6 🚀1

Hi @altescape, I was unable to reproduce on a published page using a custom field. Would you be able to create a separate issue for this as it seems like the problem you're having is different to the original report (and this issue is now closed).

content is in ACF, no WordPress default blocks used

I'm not sure what this means, it'd be good if you could add some extra steps about how you create the post when creating a separate issue.

Thanks.

talldan picture talldan on 5 Jun 2019
👍1

This has still occurred for me, although not every time I edit a published post. However, selecting "Preview" for the second or third time has shown the edited version.

vesaraiskila picture vesaraiskila on 5 Jun 2019

@altescape Having exactly the same problem (tested ACF 5.8.1 and Wordpress 5.2.1). Did you find a solution or create a new issue somewhere? I already contacted the ACF developers but they could not reproduce the issue (they said).

  • Preview saves a revision which erases all ACF fields(!), so - of course - it will show an empty page. This can be seen in the page revisions.
  • Using preview on unpublished posts or pages works as expected, just if you try to preview an already published page, it will have all ACF fields erased
  • Autosave will also remove all ACF fields content(!)

I know this issue is closed, but it could very well be that these problems are somehow related. Any help is appreciated.

kaij picture kaij on 10 Jun 2019
👍3

@kaij Hi,

I opened another issue https://github.com/WordPress/gutenberg/issues/16006 see my description there

altescape picture altescape on 11 Jun 2019

I fixed my website in the following way.

  1. not change post_modified_gmt if REQUEST_META_BOX_UPDATES action
add_filter( 'wp_insert_post_data', function ( $data ) {
  if ( isset( $_GET['meta-box-loader'] ) ) {
      unset( $data["post_modified"] );
      unset( $data["post_modified_gmt"] );
  }

  return $data;
} );

or

  1. set autosave's post_modified_gmt = original post's post_modified_gmt +1 sec
add_action( 'save_post', function ( $post_id, $post ) {
  if ( isset( $_GET['meta-box-loader'] ) ) {
      $autosave = wp_get_post_autosave( $post_id, get_current_user_id() );
      if ( $autosave ) {
          $filter = function ( $data ) use ( &$filter, $post ) {
              remove_filter( 'wp_insert_post_data', $filter );
              $data["post_modified"]     = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified ) + 1 );
              $data["post_modified_gmt"] = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified_gmt ) + 1 );

              return $data;
          };
          add_filter( 'wp_insert_post_data', $filter );
          wp_update_post( $autosave );
      }
  }
}, 10, 2 );

Where did you add the code? cause I'm trying to insert into my theme functions.php but nothing happened

Bt4ok picture Bt4ok on 25 Dec 2019

@Bt4ok -- the code was for an earlier version of Wordpress -- the issue with post previews and metaboxes that is described in this thread was resolved quite some time ago with a Wordpress update. If you are having a problem now you should report an open a new issue. (If you'll note, this thread was marked closed)

Armarsh picture Armarsh on 26 Dec 2019

@Bt4ok -- the code was for an earlier version of Wordpress -- the issue with post previews and metaboxes that is described in this thread was resolved quite some time ago with a Wordpress update. If you are having a problem now you should report an open a new issue. (If you'll note, this thread was marked closed)

Yes still have the problem
Clear wp install 5.3.2
Built-in Gutenberg
ACF 5.8.7

Problem is still present
No preview updates of changes in advanced custom fields forms if post is published.
Tried to install gutenberg as plugin - received the same problem.
Also trough time preview page get empty fields. 1click -preview - fields are empty, 2nd click - filled (saved post version without changes), 3rd-emptry, 4th - filled (without changes).
Tested on built in twentytwenty theme.

May be need to rollback for previous wp version or acf?

Bt4ok picture Bt4ok on 26 Dec 2019

This preview issue was solved for me months ago, but recently I've been experiencing this:

Auto-saving makes the preview window refresh itself continuously and frequently, which is really frustrating when one is reading through the text to see if everything is ok. After each refresh, the page is returned to the top, and one has to scroll back to the place that one was reading.

vesaraiskila picture vesaraiskila on 26 Dec 2019

https://github.com/WordPress/gutenberg/issues/12617#issuecomment-569045110

Thank you. The problem was resolved by rollback to wp 5.0 core version. Preview working as expected for drafts and published posts (including changes in ACF fields), but ACF fields automatically saved when I press the "preview" button.

Bt4ok picture Bt4ok on 26 Dec 2019

Just to be sure: is the constant realoading of the preview window, absent any modifications, "working as expected"? It really makes concentrated reading difficult.

vesaraiskila picture vesaraiskila on 26 Dec 2019

My english isn't very good, sorry.
I mean. Rolled back to wp 5.0. Entered post edit page, made some changes in acf fields or in the content section. Press "preview" and see all made changes! No matter is post published or is draft.

Only a problem is if make some changes in acf fields and press "preview" - after pressing the button I get updated (saved) post with my last changes in acf forms. Changes in content presented in "preview" mode but not saved until I press "update".

For example. Open post for edit -> make some changes to ACF fields and to post content (or title, etc.), press preview - I see all changes (acf+content). Close edit post page without pressing update but get new version post with old content and changed acf. If don't close post edit page without saving and press update, get updated post with all changes in acf and content.

I hope, my answer is understandable

Bt4ok picture Bt4ok on 26 Dec 2019

I fixed my website in the following way.

  1. not change post_modified_gmt if REQUEST_META_BOX_UPDATES action
add_filter( 'wp_insert_post_data', function ( $data ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        unset( $data["post_modified"] );
        unset( $data["post_modified_gmt"] );
    }

    return $data;
} );

or

  1. set autosave's post_modified_gmt = original post's post_modified_gmt +1 sec
add_action( 'save_post', function ( $post_id, $post ) {
    if ( isset( $_GET['meta-box-loader'] ) ) {
        $autosave = wp_get_post_autosave( $post_id, get_current_user_id() );
        if ( $autosave ) {
            $filter = function ( $data ) use ( &$filter, $post ) {
                remove_filter( 'wp_insert_post_data', $filter );
                $data["post_modified"]     = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified ) + 1 );
                $data["post_modified_gmt"] = gmdate( 'Y-m-d H:i:s', strtotime( $post->post_modified_gmt ) + 1 );

                return $data;
            };
            add_filter( 'wp_insert_post_data', $filter );
            wp_update_post( $autosave );
        }
    }
}, 10, 2 );

Where did you add the code? cause I'm trying to insert into my theme functions.php but nothing happened

I have the same question

hoangemini picture hoangemini on 27 May 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

jasmussen picture jasmussen  ·  3Comments
davidsword picture davidsword  ·  3Comments
JohnPixle picture JohnPixle  ·  3Comments
aduth picture aduth  ·  3Comments
wpalchemist picture wpalchemist  ·  3Comments