Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[Feature] Post Preview Links (v2) #5097
This is a rework from the original spec/discussion in #4595
To start with, the problem we want to solve. There are two slightly different use cases here:
Following on from the discussions that were had in #4595, lets implement post previews for our users with two different modes: private (default) and public (can be enabled/disabled). By default, the preview will be available to anyone who would normally be able to see the draft post according to the existing permissions system. If desired, the preview link can be converted to being public, and disabled when needed.
As these urls are going to be sharable, they should be short and pretty. Ideally something like
This URL should only work whilst the post is a draft, once published this URL should 301 to the proper URL. The preview route should add the private cache control header rule that we use for the admin and API, so that this page is never, ever cached as well. If the URL is in private mode, and the user doesn't have permission to see the post, the URL should respond with a 404 rather than a 403, I think.
In order to make it possible to switch between private and public mode, we'll need to add a new
The UI for getting the preview URL & the switch between private/public are still in the works. There will be a need to inject code into the preview using the ghost_head/foot mechanism so that we can clearly mark the view as a preview and perhaps include other UI elements. Therefore I think it makes sense to implement the private preview URL first, and then layer on the sharing functionality as a second piece.
Looks very good
I would not promote a short link because the link is public, but the post is not published. Having a differentiation between private and public preview was intended to help prevent user error. Short links could still be easy to guess. The link is going to be copied/pasted anyway.
Github Gist uses 20 chars which looks quite reasonable to me?
The 4/5 char concept was based on things like bit.ly and cl.ly - the URL is only public if it is converted to public by the user, and they can then disable this again.
I think this goes back to the original discussion - this is a feature for 90% of users, the users who need more security when sharing will need a different form of sharing (with specific people or email addresses etc) which is an extension of this feature that would sit well in an app.
This will probably need some further discussion, because this is painfully complex - but here's what I'm thinking so far:
I click on the "preview" link ^ above and a new window opens with a preview of my post. Whatever URL this preview appears on is accessible by anyone with >= Editor permissions.
Create a preview link
Clicking on "get preview link" generates a new short URL which is accessible to anyone who has the link. This can be copied/pasted or disabled. If disabled, we revert to screenshot 1 above. If the "get preview link" is clicked again - a new short URL is created and the old one is invalid. (NB: @ErisDS I don't think preview links need to be 301'd to final posts - they should always be ephemeral)
View preview link
If I view this preview-link as anybody except the author of the post, the preview toolbar shows a simple notification:
To avoid style-clashes with the theme:
Would it be possible to move the preview bar to the top of the page? I realise there is likely good reason for its current location, however from a technical perspective putting the toolbar just above
Injecting at the top or bottom is relatively straightforward due to us always knowing where that is within the DOM. Injecting it right above
Using the content helper is absolutely a possibility here, just not preferable, IMO.
This was referenced
Apr 21, 2015
added a commit
Apr 27, 2015
So, my POC became somewhat more serious in an effort to break out the implementation of this into three seperate phases
As with all new features, we also need to think about
The problem with hashids
Preview for all posts is implemented in #5158. We initially set out with the hope of also implementing hashids via the
So, that needs some consideration.
referenced this issue
May 10, 2015
There should be a way to customize templates for preview to exclude scripts you don't want to run.