Previews should redirect to the permalink if the post has been published

[evansolomon]

If a post is saved as a draft and you visit the preview URL, even after the post is published, you will stay on the preview view (with preview=true in the URL). This is confusing since you're not actually previewing anything, you're viewing a public post.

Are you talking about someone clicking on the Preview Changes button to get to the Preview URL, or refreshing/copy/pasting the URL? I think I disagree with the suggestion in both cases, but want to be sure I understand which scenario you're talking about before posting counter opinion.

If ?preview=true and ! $_POST (does it work via $_GET?), we can probably shave off the query var in canonical. Makes sense, as that URL shouldn't be distributed.

Replying to jane:

Are you talking about someone clicking on the Preview Changes button to get to the Preview URL, or refreshing/copy/pasting the URL?

Neither, at least not specifically. Here is a way to get to the point I'm talking about:

1) Write a post and save it as a draft
2) Send a link to the post preview to someone else (i.e. "What do you think of this post? [link]")
3) Get impatient waiting for your friend to reply and publish your post
4) Now your friend clicks on your "preview" link

At step 4 there's nothing being previewed, just a confusing URL that looks like it is. Your friend is viewing a public post that would work without the "preview=true" in the URL, whether or not they have any capabilities on the blog. If the "preview=true" were removed, it would run through redirect_canonical() and send the user to the post permalink.

Nacin's interpretation is exactly what I intended.

This just popped up in the forums. Here's a fun example.

​http://ipstenu.org/?p=1917&preview=true

The page is published, but it doesn't redirect.

Worse another person is having a problem where a NON published page is showing something.

​http://wordpress.org/support/topic/redirecting-page-preview

And it's showing up in Google.

Replying to Ipstenu:

Worse another person is having a problem where a NON published page is showing something.

Looking at the thread, this doesn't seem to be the case. The page appears to be published.

It wasn't showing published at the time. When I hit the page sans preview it was a 404.

&preview=true only works if you are a logged-in user with permission to edit that post. If you are not logged in, it is impossible (without a plugin deliberately or accidentally making changes to a deep area of WP_Query) to view a non-published post.

There's no information disclosure bug here. At most, that's a misunderstanding. The issue is purely canonically redirecting the link once the post is published, in case it is shared.

Previews work for both un-published and published posts. In the first case the post is shown on the front end.

In the second case the post_content is taken from the editor and shown on the front end, so when previewing a published post, you are looking at any edits/changes made since the post was published. That's why the button's name changes to Preview Changes.

So, to answer directly to the concern in the ticket:

"This is confusing since you're not actually previewing anything, you're viewing a public post."

No, you are not viewing a public post, you are previewing changes made since the post was published.

No, you are not viewing a public post, you are previewing changes made since the post was published.

Not quite — that's only if the link has a preview_id and preview_nonce.

A draft post that is ?p=1234&preview=true does not trigger a preview once the post is published. It simply loads the post. The preview query variable is ignored. This ticket is about removing the preview query variable in this case and doing a canonical redirect to wherever ?p=1234 should go.

Ah, I see. So this would only cover the cases where a preview link was opened by another user, then the original author has published the post and the other user refreshes the preview page instead of going to the permalink for the published page. Seems like quite rare edge case.

Related: #21765

#23344 was marked as a duplicate.

added patch