Preview fails to display edits in Gutenberg

[Armarsh]

Describe the bug
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.

(Same as issue #12617 which was closed -- but this is NOT a plugin issue and should NOT be closed or ignored based on the fact that the problem also can be reproduced with some plugin conflicts.)

[designsimply]

Noting that #12617 had some speculation come up in the comments and a plugin conflict was tested and confirmed and that opening a new issue with the relevant details for your case is a good route. I'm copying over some relevant information from your comment at #12617 (comment) for reference:

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.

[designsimply]

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

[talldan]

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.

@Armarsh I couldn't reproduce this, if you could provide some details reproduction steps that'd be really helpful. Here's the capture of my test:

[Armarsh]

This problem was already described at length in #12617 by multiple posters -- the problem was pretty clearly described by many. I opened this thread after #12617 was retitled and closed because of a separate plugin conflict that was not tied to or mentioned in the original report.

There is also a demo posted #12717 - see this link https://www.youtube.com/watch?v=FhCssW8JpEc&feature=youtu.be

@talldan -- here's my question for you: what is the size of the database for the wordpress installation you are using for testing? If you are using a clean, new installation then you aren't going to see the problem. So I think it's best tested on a well-established, larger site.

[Chrico]

Howdy,

i can reproduce this behavior as well, but just for post_status = 'private'. As soon as i switch to public and add elements, the preview is working. If i switch back to private and add elements, they will not appear in preview mode.

Can anyone reproduce or confirm it with post_status = private? @Armarsh

---

Edit: Sry, it seems i was wrong. There's following behavior locally:

v1. Page is "public" -> do changes -> preview ✔️

v2. Page is "public" -> do changes -> change to "private" -> preview ✔️

v3. Page is "public" -> change to "private" -> do changes -> preview ❌

v4. Page is "public or private" -> do changes -> preview ❌

When clicking "preview" is "saved" via REST API, but the changes are not visible in frontend.. 🤔

If i look into the Network-Tab of Chrome, there's a request to the REST API /wp-json/wp/v2/pages/{id}/autosaves?_locale=user done with Payload:

content: "<!-- wp:paragraph -->↵<p>test2</p>↵<!-- /wp:paragraph -->"

Which is correct. But in frontend there is still "test" just visible.

[Chrico]

Sry for commenting twice..on my local machine the error is not there, but on stage and production it's there (same Server, PHP, Database, Plugins, ...).
It seems, that this error is not present when dealing with "slower" machines. I'll try to remote debug this now, but this may can take a while until i can get an enviornment where i can rebuild it.

Locally in wp-includes/revision.php in _set_preview-function uses already the correct post, so it's stored in DB before the preview is rendering.

What i can see so far is, that in PostPreviewButton-Component the openPreviewWindow [1] maybe should wait until the savePost or autosave is finished before loading the preview. Since this is running async and after opening/refreshing the preview window [2] it may can happen that the preview is rendered, before the actual post is available for previewing.

[1] PostPreviewButton::openPreviewWindow

gutenberg/packages/editor/src/components/post-preview-button/index.js

Line 132 in 2575d23

openPreviewWindow( event ) {

[2] async updating of Post after opening Preview

gutenberg/packages/editor/src/components/post-preview-button/index.js

Lines 157 to 163 in 2575d23

	// Request an autosave. This happens asynchronously and causes the component
	// to update when finished.
	if ( this.props.isDraft ) {
	this.props.savePost( { isPreview: true } );
	} else {
	this.props.autosave( { isPreview: true } );
	}

[designsimply]

Based on the information in #12617 (comment) 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)

[designsimply]

Based on the information in #13232 (comment) I ran the following test:

1. Open a previously published post.
2. Go to Settings > Document > Status & Visibility and change "Public" to "Private".
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 to previously published private posts work normally for me in testing on a site with a database that is 5.8 MB.

[Armarsh]

@designsimply - thanks for trying to test this -- but I do think that if it is tied in any way to database response time then it is going to vary depend on server configuration and resources. So maybe a site running in a shared hosting environment with one provider is going to have the problem, and if the same site were moved to a different server it won't have the problem anymore. And in a shared hosting environment, there are also going to be problems completely outside the control of the tester, such as the impact of resource usage from other users on the system.

Maybe you can keep on trying on jurassic.ninja to push until you get to whatever is enough to trigger the problem -- or maybe that site has a configuration that is better optimized for wordpress than the hosts and servers used by those of us reporting the problem.

So probably the best way to test is on a server that is known to have this issue.

[designsimply]

Thanks! Yes, if it is indeed a race condition, those can be pretty tricky to nail down. It's still a really good idea to try to keep searching for a good set of reliable steps to reproduce the problem, even if the bug is a bit elusive! 🐛🤨

[talldan]

Hi @Chrico Thanks for looking into that. The post preview button should handle the asynchronous nature of the save.

The steps that happen are:

1. The preview window/tab is opened if required
   

   gutenberg/packages/editor/src/components/post-preview-button/index.js

   Lines 140 to 143 in ad4c9e7

   	// Open up a Preview tab if needed. This is where we'll show the preview.
   	if ( ! this.previewWindow || this.previewWindow.closed ) {
   	this.previewWindow = window.open( '', this.getWindowTarget() );
   	}

2. If the post is autosaveable, it is saved (or if not autosaveable, the current post is shown and the following steps don't happen)
   

   gutenberg/packages/editor/src/components/post-preview-button/index.js

   Lines 150 to 163 in ad4c9e7

   	// If we don't need to autosave the post before previewing, then we simply
   	// load the Preview URL in the Preview tab.
   	if ( ! this.props.isAutosaveable ) {
   	this.setPreviewWindowLink( event.target.href );
   	return;
   	}
   	// Request an autosave. This happens asynchronously and causes the component
   	// to update when finished.
   	if ( this.props.isDraft ) {
   	this.props.savePost( { isPreview: true } );
   	} else {
   	this.props.autosave( { isPreview: true } );
   	}

3. A loading screen is shown in the preview window
   

   gutenberg/packages/editor/src/components/post-preview-button/index.js

   Lines 165 to 167 in ad4c9e7

   	// Display a 'Generating preview' message in the Preview tab while we wait for the
   	// autosave to finish.
   	writeInterstitialMessage( this.previewWindow.document );

4. When REST request to save the post is complete, the PostPreviewButton component previewLink prop is updated and the PostPreviewButton componentDidUpdate method updates the preview window to show the latest post
   

   gutenberg/packages/editor/src/components/post-preview-button/index.js

   Lines 102 to 125 in ad4c9e7

   	componentDidUpdate( prevProps ) {
   	const { previewLink } = this.props;
   	// This relies on the window being responsible to unset itself when
   	// navigation occurs or a new preview window is opened, to avoid
   	// unintentional forceful redirects.
   	if ( previewLink && ! prevProps.previewLink ) {
   	this.setPreviewWindowLink( previewLink );
   	}
   	}
   	/**
   	* Sets the preview window's location to the given URL, if a preview window
   	* exists and is not closed.
   	*
   	* @param {string} url URL to assign as preview window location.
   	*/
   	setPreviewWindowLink( url ) {
   	const { previewWindow } = this;
   	if ( previewWindow && ! previewWindow.closed ) {
   	previewWindow.location = url;
   	}
   	}

Are either you or @Armarsh using metaboxes when you experience the issue? They very slightly change how the preview button works.

[Armarsh]

@talldan -- I'm not sure what a metabox would be or include. Can you give me an example on the simplest level? (that is, something that would commonly be used in a simple theme).

[talldan]

They're a way to add extra metadata to a post. A plugin might add extra metadata/metaboxes. They can appear as extra options in the sidebar or at the bottom of the editor.

Custom Fields are the most accessible way to add metadata (enabled in Gutenberg in the Options dialog, accessible from the menu in the top right corner).

My understanding is that Gutenberg has no way of identifying when a metadata value has changed and needs to be saved, so the behaviour of the preview button changes to save every time it's clicked, just in case there is an unsaved metadata change.

I've just done a run-through, and using a custom field is the only way I've reproduce this issue yet. Here's the steps:

1. Start a new post
2. Open the options dialog from the Editor 'more' menu. (The menu accessible from the top right corner, icon looks like the three stacked dots)
3. Enable the Custom Fields option
4. Add a new custom field
5. Add a title and content to the post and save
6. Add some extra text to the post content and click the preview button
7. Observe that the changes made are not reflected in the preview

I wonder if that's main culprit.

[Armarsh]

I have 9 sites, all on the same shared server, showing the problem.

I have been doing checking while following this thread on one of the more simple sites. This site does not have any custom fields activated.

I do have some other sites that have custom fields --- but I have been doing the testing for this function on the site that has the simpler structure.

I'd note that I don't believe I have the Gutenburg custom fields in use on any of these sites -- these are all well-established sites so not really creating anything new. However, some of the sites do have custom fields created with different plugins. But again, I've tested on all sites on my server - and the process to create the error is the same for all.

[talldan]

Are you able to let us know what plugins you have active on the site with the simpler structure? I think both @designsimply and I have been able to establish that the bug doesn't happen with a fresh install, it'd be great to narrow this down.

[Armarsh]

But the problem persists with all plugins deactivated --- I just tested once again to confirm that.

So I just don't think it's a plugin issue.

I'd note that if install the Health Check & Troubleshooting Plugin and run the troubleshooter, the problem goes away --- even with all plugins enabled --- but that plugin is creating some sort of shadow session that is running separately.

[Chrico]

I think the solution is posted here: #12617 (comment) - seems that, when having Metaboxes, the save routine does not work correctly when clicking "preview".

[v33dub]

Just wanted to comment that I have been experiencing this issue - I have several sites on the same server, the much smaller 1-5 page sites have no problem previewing, but the larger sites do. None of my sites are using Metaboxes, so I don't think it's related.

[Armarsh]

As already noted, I also have sites that do not have metaboxes that have this problem.

Just because some users can trigger the problem with certain plugins or theme/site modifications doesn't mean that is the cause of the problem on all sites.

I understand that it's difficult to debug without being able to reliably replicate the problem. It's just that it's not helpful to over-generalize. There may be multiple different scenarios that cause this bug to manifest, and it probably varies on different platforms and configurations.

[kristarella]

I was able to replicate this issue on a number of sites and for one of them I tried clearing the cache (via WP CLI) and reloaded the preview, which revealed the change in the preview (while public page is still showing the previous published version).

This could be one reason that the problem is hard to reproduce: different sites and servers have different caching settings.

I'm not sure what further information is helpful for this, so if you would like more info for setup of the sites I was testing please ping me.

[earnjam]

From an Autosave firing in the editor. Close your editor window and the preview window will no longer refresh.

[Armarsh]

@Armarsh I just want to confirm, you've been able to replicate the issue consistently with no plugins active and set to the default theme?

I did that before my initial report -- disabled all plugins & set default theme to test. I did not repeat that after reporting the changes post 5.1, in part because others reported similar issues. As noted, this is consistent across most of my sites on a shared VPS server, with a variety of different themes & plugins.

[earnjam]

Ok, well the reason I ask is this comment.

But the problem persists with all plugins deactivated --- I just tested once again to confirm that.

So I just don't think it's a plugin issue.

I'd note that if install the Health Check & Troubleshooting Plugin and run the troubleshooter, the problem goes away --- even with all plugins enabled --- but that plugin is creating some sort of shadow session that is running separately.

The Health Check & Troubleshooting plugin's troubleshooting mode deactivates all plugins and uses a default theme for requests from the current user.

Some themes add metaboxes to the editor as well. It's possible if you only deactivated plugins in your testing (or didn't do both plugin and the theme at the same time), then your theme may be adding metaboxes to the editor, which would be triggering the problem identified in #12617.

[kristarella]

I heard that the Preview code has changed, and in my latest tests I can no longer replicate this problem where I could before. Can anyone else confirm the symptoms are resolved for them?

[talldan]

@kristarella Yep, in my testing it seems to be resolved 🎉

Would love to know what the change was that resulted in the fix.

[Armarsh]

NO FIX FOR ME -- I'm seeing the same problem with WP 5.1.1. as reported above. Preview function does not work for published posts.

[talldan]

@Armarsh There's a good chance the fix hasn't made it into a release yet. The next release for the plugin should go out on Wednesday.

[kristarella]

@Armarsh Thanks, my test was not thorough enough earlier. Just tried again with three different sites, with new and old published pages and edits do not show.

Any draft shows preview normally. Any published or private post does not show edits in the preview, but switching from published to private, or private to published, or switching to draft causes the edits to show in preview.

And as you noted earlier, clearing cache and reloading preview no longer works as it did for me in previous versions.

[kristarella]

@talldan Not sure it is fixed actually. Which version are you testing?

[Armarsh]

@talldan What plugin are you referring to? This is a core WP problem for me -- multiple sites, and tested before I opened this thread by disabling all plugins & reverting to TwentyNineteen theme.

[earnjam]

@Armarsh this plugin. Development of the editor occurs here and then is merged into core at each release. I have not tested yet, but @talldan is saying the bug is no longer occurring in the latest on the master branch of this repo. It’s not in core yet.

[Armarsh]

@earnjam - Ok, thanks for the explanation. Is there a link where we non-developers can download the pre-release plugin to test?

[earnjam]

From the main page on this repo, there is a link to download a zip file, but you will need npm installed to build it in order for it to work.

Once the next plugin version is released (which isn’t too far off), you will be able to install/test it from the Wordpress.org plugin repository like any other plugin.

[talldan]

@kristarella testing in a development environment using the code checked out from the repo. It would be great to get some further confirmation, hopefully when the plugin is updated next week or in the upcoming 5.2 release.

[talldan]

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

Sorry to get everyone's hopes up.

[earnjam]

I've mentioned before, but that's not how it works.

[locksoft]

Still no solutions?

[youknowriad]

Based on this comment #14877 (comment) and #14877 I think this can be closed now, right?

[talldan]

Yep, I'll close it, we can always reopen it if it does continue to be an issue. I'm hopefully looking forward to this one being fixed for everyone, though 👍

[arnisjuraga]

UPDATE: The same problem exists, with ALL plugins disabled, but Advanced panels > Custom Fields displayed in post edit. The same Javascript error in ajax.

I had a problem with WordPress 5.1.1 and ACF (v.5.7.12) plugin. With ACF enabled and one custom field defined for "post" type, preview is working till first live Publish.

Editing posts afterwards and pressing "Preview" button, it displays a message in Ajax response visible only in dev tools:

And changes are not visible on Preview page, of course.
I have tried to change themes but problem persists.

[earnjam]

@arnisjuraga 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 core until 5.2 comes out next week.

[arnisjuraga]

No, haven't tested. Let's leave it then. Will wait for latest upgrade and will check then.

[arnisjuraga]

5.2 update did not help. What's next?

[earnjam]

@arnisjuraga can you open a new issue with specific details about your error and what plugins you have active? I would also suggest testing it with all plugins disabled and default theme active.