Automattic / wp-calypso

The JavaScript and API powered WordPress.com
https://developer.wordpress.com
GNU General Public License v2.0
12.4k stars 1.98k forks source link

Preview: Showing errors or out of date information. #52178

Open sstabrizi opened 3 years ago

sstabrizi commented 3 years ago

I've had several reports that the preview function isn't working for some users, specifically when a post is unpublished or scheduled. For example, a title was updated to what is shown in the screenshot below:

Screenshot on 2021-04-21 at 15-03-46

Once I hit preview this is what is shown:

Screenshot on 2021-04-21 at 15-06-23

Notice that the title is incorrect.

I also had a report of an Oops/404 page not found when previewing a drafted post. In both cases, the post could be viewed by going to the direct post link.

inaikem commented 3 years ago

Hi @sstabrizi! Please update this with an interaction link(s), and/or any test sites you were able to replicate this on.

I'm closing this for now but please reopen with the requested details, thanks!

sstabrizi commented 3 years ago

Site: ecclesiastesamplified.com - Atomic Interaction: 29152016-hc I was not able to replicate this on any site, I was just noting the bug as I encountered it during chat.

kriskarkoski commented 3 years ago

The above was me reopening this issue after talking with @sstabrizi, but I was logged into a different account due to some changes I'm working on :)

dsas commented 3 years ago

Reproduction

I can reproduce this on both atomic and simple sites using these steps

  1. Use calypso to open the add new post screen
  2. Set the title to 'Title' and publish (the post needs to be published rather than a draft)
  3. Change the title to 'Title 2' and press preview - it will say 'Title 2'
  4. Change the title to 'Title' and press preview - it will remain as 'Title 2' rather than updating

The key thing is to change the title back to whatever the title was in the most recent published/saved version of the post.

I've also reproduced it on a jurassic ninja site that doesn't have jetpack connected.

What's going on

Wordpress (gutenberg) will auto-save the editor state before previewing and then presumably the preview will always show the most recent save. It adds an autosave using the autosave API https://public-api.wordpress.com/wp/v2/sites/$siteid/posts/$postid/autosaves

The first preview generates an API request with a body of

{"status":"publish","title":"Title 2","content":"","excerpt":""}

The second preview generates a completely identical API request

{"status":"publish","title":"Title 2","content":"","excerpt":""}

i.e. it's sending the same title, not the recently updated one

dsas commented 3 years ago

Looks like this Gutenberg issue: https://github.com/WordPress/gutenberg/issues/21191

dsas commented 3 years ago

Using react dev tools, gutenberg's AutosaveMonitor isDirty prop is set to false if the content matches the saved version and true otherwise. Not sure if that is related :)

cpapazoglou commented 3 years ago

I tried reproducing the issue today without any luck. Every time I edited the title and clicked "Preview" (without saving) the https://public-api.wordpress.com/wp/v2/sites/$siteid/posts/$postid/autosaves contained the newly updated title, description, excerpt and thus the Preview was appearing OK.

Can you check once again @dsas ?

gavande1 commented 3 years ago

I was able to reproduce the issue by following the steps mentioned by @dsas but it's reproducible with the published post. If the post is in the draft state then the issue is not reproducible as mentioned by @cpapazoglou.

cpapazoglou commented 3 years ago

Ok, I have managed to reproduce it only in an unlaunched "Coming Soon" site. @dsas, @gavande1 can you confirm this?

Also, in my case https://public-api.wordpress.com/wp/v2/sites/$siteid/posts/$postid/autosaves always contained the correct values but the Preview always showed the initial value.

Also, I can't reproduce it on vanilla Gutenberg so this has to be a WPCOM only issue.

Scratch that. I just reproduced three Gutenberg issues:

  1. WordPress/gutenberg#21191, as @dsas found. Probably this is loosely connected to the current issue though
  2. WordPress/gutenberg#33616
  3. WordPress/gutenberg#33758