Update "Preview" button to "View" if there are no changes

[folletto]

Currently we show a "Preview" button even when the post has no changes — marked by "Update" being disabled:

What are we "pre-viewing" if the post is the same? It always makes me wonder if the "Preview" link does something different from just getting me to the post on the front-end.

Unless I'm missing a reason for this, I feel that the button should be marked as "View" if there are no changes, thus having these two states:

If there aren't changes:

If there are changes:

[ZebulanStanphill]

The preview tab refreshes automatically to reflect changes in the editor, so technically the Preview button does have a different effect than a simple "View" button. It's a live-reloading view of the latest version of the post (published or unpublished).

[folletto]

I just realized what you just said... is the cause of another issue I couldn't identify — ghost auto-saves. It seems that every time I click "Preview" it generates one, even if the post has no edits, and triggering this "Auto-Save" error in case of reload:

If this is the case, then it's not just a very opaque feature — it's also creating the problem above.

I'd think that changing to "View" and only triggering "Preview" when there's actually the need of an auto-save the it would solve both problems.

[youknowriad]

The UI changed with the devices dropdown, I believe we can close this issue now.

[aduth]

I just realized what you just said... is the cause of another issue I couldn't identify — ghost auto-saves. It seems that every time I click "Preview" it generates one, even if the post has no edits, and triggering this "Auto-Save" error in case of reload:

It would be worth testing to see if this still happens with the "Preview externally" link in the new preview dropdown. I sense it probably behaves the same as it did previously (including the redundant saves?)

Seems like it may be a related but separate issue than that originally reported here. Would be good to have tracked if it still occurs.

Noticed a related Trac ticket: https://core.trac.wordpress.org/ticket/49532 (should probably be tracked in GitHub instead/in addition)

[aduth]

Ah, I see that @Inwerpsel reported this at #20505 as well.

[folletto]

The UI changed with the devices dropdown, I believe we can close this issue now.

I don't think the new UI addresses the issue I raised here. The dropdown doesn't solve the ambiguity of view/preview, if anything, makes it worse.

This was raised again as an issue in slack:
https://wordpress.slack.com/archives/C02S78ZAL/p1583429569244200

And a new issue was opened:
#20602

[jasmussen]

Reopening this per discussions in #20602.

[folletto]

To summarize the discussion that overlapped in the other thread, we need to:

• have both a "View" if no-changes or "Preview" if changes (UI side)
• have a fix: "View" shouldn't trigger a revision being created (API side)

[shaunandrews]

I don't think most people will understand the distinction between Preview and View — nor do I think most people will even notice the label changing at all.

With that in mind, I think this suggestion adds complications to the UI with no real benefit to the end user.

[folletto]

Even if it's not a major issue, I disagree. This emerged already multiple times, and dismissing it doesn't make us a favor. The last one was highlighted in the Slack chat above.

It's fine if people won't notice the difference, it's not meant to be a big change, so that's a fine outcome. Yet the underlying logic is important. It's not just a label change (notice the two bullet points above). It also changes the behaviour.

[Mamaduka]

Should we close this now that there's a separate "View Post" button for published posts?

[jasmussen]

I'll tentatively close this one as fixed by the following flow:

Though I will also point to conversation on this thread where it's discussed whether we can show the "View post" button always, not just when a post is published first. That issue can be reopened if need be, as it contains some valid nuance from a developer. And with this link it should also be connected to this older issue for even deeper context!

And even if closing here is in error, we can always reopen 🙏