New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preview fails to display edits in Gutenberg (current theory of the problem: autosave is triggered a 2nd time by metaboxes without post edits and the edits therefore don't show up in a preview) #12617

Open
davidAIS opened this Issue Dec 5, 2018 · 79 comments

Comments

@davidAIS
Copy link

davidAIS commented Dec 5, 2018

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

This comment has been minimized.

Copy link
Contributor

designsimply commented Dec 5, 2018

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?

@davidAIS

This comment has been minimized.

Copy link
Author

davidAIS commented Dec 6, 2018

@designsimply

This comment has been minimized.

Copy link
Contributor

designsimply commented Dec 6, 2018

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

This comment has been minimized.

Copy link
Author

davidAIS commented Dec 6, 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.

@designsimply

This comment has been minimized.

Copy link
Contributor

designsimply commented Dec 6, 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.

@slimmilkduds

This comment has been minimized.

Copy link

slimmilkduds commented Dec 8, 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

@designsimply

This comment has been minimized.

Copy link
Contributor

designsimply commented Dec 12, 2018

Thanks @slimmilkduds!

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

@davidAIS

This comment has been minimized.

Copy link
Author

davidAIS commented Dec 12, 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.

@xy0

This comment has been minimized.

Copy link

xy0 commented Dec 13, 2018

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

This comment has been minimized.

Copy link

amycmcc commented Dec 14, 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.

@designsimply

This comment has been minimized.

Copy link
Contributor

designsimply commented Dec 18, 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?

@Armarsh

This comment has been minimized.

Copy link

Armarsh commented Dec 18, 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.

@xy0

This comment has been minimized.

Copy link

xy0 commented Dec 18, 2018

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

This comment has been minimized.

Copy link

Armarsh commented Dec 19, 2018

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

This comment has been minimized.

Copy link

scottbuscemi commented Dec 20, 2018

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

This comment has been minimized.

Copy link

scottbuscemi commented Dec 21, 2018

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

@davidAIS

This comment has been minimized.

Copy link
Author

davidAIS commented Dec 21, 2018

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

This comment has been minimized.

Copy link

scottbuscemi commented Dec 21, 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...

@Armarsh

This comment has been minimized.

Copy link

Armarsh commented Dec 21, 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.

@slimmilkduds

This comment has been minimized.

Copy link

slimmilkduds commented Dec 21, 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).

@designsimply

This comment has been minimized.

Copy link
Contributor

designsimply commented Jan 17, 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.

@johnnyontheweb

This comment has been minimized.

Copy link

johnnyontheweb commented Jan 18, 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?

@IreneStr

This comment has been minimized.

Copy link
Member

IreneStr commented Jan 22, 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.

@designsimply designsimply changed the title Preview fails to display edits in Gutenberg (possible plugin conflict with Yoast SEO & Advanced Custom Fields) Preview fails to display edits in Gutenberg (current theory of the problem: autosave is triggered a 2nd time by metaboxes without post edits and the edits therefore don't show up in a preview) Jan 22, 2019

@designsimply

This comment has been minimized.

Copy link
Contributor

designsimply commented Jan 23, 2019

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.

@talldan

This comment has been minimized.

Copy link
Contributor

talldan commented Jan 23, 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.

@youknowriad

This comment has been minimized.

Copy link
Contributor

youknowriad commented Jan 23, 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?

@dlh01

This comment has been minimized.

Copy link
Contributor

dlh01 commented Jan 24, 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.

@talldan

This comment has been minimized.

Copy link
Contributor

talldan commented Jan 24, 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:

subscribe( () => {
const isSavingPost = select( 'core/editor' ).isSavingPost();
const isAutosavingPost = select( 'core/editor' ).isAutosavingPost();
const isPreviewingPost = select( 'core/editor' ).isPreviewingPost();
const hasActiveMetaBoxes = select( 'core/edit-post' ).hasMetaBoxes();
// Save metaboxes on save completion, except for autosaves that are not a post preview.
const shouldTriggerMetaboxesSave = (
hasActiveMetaBoxes && (
( wasSavingPost && ! isSavingPost && ! wasAutosavingPost ) ||
( wasAutosavingPost && wasPreviewingPost && ! isPreviewingPost )
)
);
// Save current state for next inspection.
wasSavingPost = isSavingPost;
wasAutosavingPost = isAutosavingPost;
wasPreviewingPost = isPreviewingPost;
if ( shouldTriggerMetaboxesSave ) {
store.dispatch( requestMetaBoxUpdates() );
}
} );

@bonlando

This comment has been minimized.

Copy link

bonlando commented Jan 29, 2019

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

@gziolo

This comment has been minimized.

Copy link
Member

gziolo commented Jan 30, 2019

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.

@earnjam

This comment has been minimized.

Copy link
Contributor

earnjam commented Jan 30, 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

This comment has been minimized.

Copy link
Contributor

earnjam commented Jan 31, 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.

@talldan

This comment has been minimized.

Copy link
Contributor

talldan commented Feb 1, 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

@MarkRH

This comment has been minimized.

Copy link

MarkRH commented Feb 7, 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.

@talldan

This comment has been minimized.

Copy link
Contributor

talldan commented Feb 7, 2019

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

@marcber

This comment has been minimized.

Copy link

marcber commented Feb 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment