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

[davidAIS]

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.

[designsimply]

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?

[davidAIS]

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.

[designsimply]

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.

[davidAIS]

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.

[designsimply]

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!

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.

[slimmilkduds]

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

[designsimply]

Thanks @slimmilkduds!

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

[davidAIS]

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.

[xy0]

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.

[amycmcc]

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.

[designsimply]

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?

[Armarsh]

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.

[xy0]

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?

[Armarsh]

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.

[scottbuscemi]

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]

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

[davidAIS]

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!

[scottbuscemi]

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

[Armarsh]

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

[slimmilkduds]

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

[garretthyder]

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

[designsimply]

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!!

[Armarsh]

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.

[scottbuscemi]

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

[garretthyder]

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

[Armarsh]

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.

[hyptx]

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.

[scottbuscemi]

Has anyone notified Yoast?

[hyptx]

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

[scottbuscemi]

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.

[slimmilkduds]

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

[litemotiv]

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.

[skrysmanski]

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:

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.

[Vixxd]

After disabling Yoast I'm still having this issue.

[hyptx]

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.

[designsimply]

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.

[litemotiv]

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.

[Armarsh]

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

[designsimply]

@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]

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

[Armarsh]

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

[designsimply]

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!

[litemotiv]

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.

[designsimply]

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.

[scottbuscemi]

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

[litemotiv]

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

[designsimply]

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]

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.

[davidAIS]

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.

[toratiger]

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.