[WIP] Add view post link on publish and update post

[cobbspur]

closes #1756

Adds a link to post url to 'post updated' and 'post published' notification

[cobbspur]

http://puu.sh/cDqNR/6a02885459.png

[ErisDS]

Following on from the comments inline...

We need to get hold of the URL on the client, but there's a tonne of logic for this server side which we ought not to be duplicating so this leaves us 3 options as I see it:

1. create a shared library for generating URLs
2. we add an API endpoint to generate the URL for a post
3. we add url as a computed property to the post object

I don't know what 1 would look like as we've not done anything like it before. 2 seems lame as we already do a API requests for a post, which leads me to think 3 is the right answer. 3 would also solve #3961. The hard part of 3 would be making sure that changing the permalink still worked (clear the post store if it changes?).

A completely different approach would be to implement draft previews. My idea for this has been to make posts (even drafts) available at my-ghost-blog.com/uuid. If the post is not published, the post would show on this URL, if it is published, this URL would redirect. But this needs a lot of thought in terms of whether this is a good solution.

This just got a lot more complex, but really needs solving :/

[JohnONolan]

My idea for this has been to make posts (even drafts) available at my-ghost-blog.com/uuid. If the post is not published, the post would show on this URL, if it is published, this URL would redirect. But this needs a lot of thought in terms of whether this is a good solution.

👍

[nuclearpengy]

That's an interesting idea. My only concern here is would this be user manageable?

Could I for example, choose whether or note my posts are publicly accessible via /uuid or not. Could this perhaps be toggled on/off per post or globally. I for one would not like someone to be able to access my posts, if I haven't enabled the function or consciously made the post visible.

These URLs should not show up in the sitemap(but I guess that's covered as a separate issue).

My approach to this would be a step between draft and published to make this URL visible.

• Draft - it's private, I don't want anyone else to access it. It could be used for personal ramblings or an idea i'm working on, but it's private and no one else should be able to access it without logging into the backend.
• Preview (for lack of a better term) - the /uuid is accessible and I could share this link with friends or trusted parties to review my posts and give feedback prior to publishing.
• Published - as it currently works, via /date/postname or just /postname :-)

[ErisDS]

Could I for example, choose whether or note my posts are publicly accessible via /uuid or not.

UUIDs are universally unique identifiers, they are random and cannot be guessed. No one will have access to your posts unless you explicitly give them a link.

[nuclearpengy]

Thank you for the feedback. I'm not publishing anything top secret, but figured I'd throw it out there. :-D

Hopefully soon massive newspapers and magazines will be publishing on Ghost and they might want their draft posts "secret" to prevent competitors stealing their stories, but I guess they could have an offline process if they're not comfortable with the UUID approach prior to publishing.

Thinking about it now, is there any value in having an "explainer" or notice somewhere, similar to how the "privacy" points are being covered, something that explains how data is accessible.

The Ghost backend UI is perfect(as in really easy to use) for personal never to be published notes, so if someone starts storing seriously personal "dear diary" type content and it gets leaked due to UUID being accessed somehow perhaps via a script written to exploit the UUID urls, then it could be embarrassing...

[nuclearpengy]

Sorry if I'm going off topic... just thinking in text. :)

[ErisDS]

I'm sure that people will want to write an app which makes preview a switchable feature, but it doesn't make sense as a default. Adding an option is always significantly more complex than not having one, which is why we always opt for what we consider to be the most sensible default.

A UUID is (unless your password is mega-strong) significantly harder to guess or exploit than a password, so if someone really wanted to go to the trouble of getting hold of your drafts, they'd probably have a way easier time trying to crack your password.

[nuclearpengy]

Good point. Thank you.

UUID > Password :-D

[sebgie]

I'm sure that people will want to write an app which makes preview a switchable feature, but it doesn't make sense as a default.

I disagree. I would really recommend to make the public preview optional. I compare this feature to Dropboxs shared links. Making all posts publicly available would be the same as to Dropbox saying that every file that is stored is publicly available using a UUID, but that is okay since you can't guess the UUID.

Links are passed around and if someone is not cautious we end up with a security vulnerability (http://blog.emsisoft.com/2014/05/07/warning-dropbox-and-box-file-sharing-security-bug/) that can't be controlled.

[novaugust]

I second the sebgie

[ErisDS]

If people aren't comfortable with preview by default, then we need to shelf that for now and have a discussion about what the right approach is & how to implement it.

That leaves us to focus on finding a good way to get the URL on the client side (which we need to do anyway). I think that adding the permalink as a computed property which is always returned from the API / model makes the most sense? We already do a similar override to the toJSON function in the user model in order to remove the password hash from the response, we could do the same to add a property to posts.

As I mentioned previously, this would allow us to reduce the complexity of the URL helper as well - it would no longer need to be async. Also, as I mentioned in my previous comment, if we store the computed permalink property and return it from the API, we need to make sure that changing the permalink structure in the admin triggers all posts to be deleted from the Ember store.

Further, I think it would significantly simplify the work @jillesme is doing in #4322 as we'd already know what the valid URL for a particular post is. Perhaps @jillesme could do this refactor as part of that work, and this PR could then simply be updated to use the new property and only display for published posts?

[jillesme]

I'm totally down for it! Unless it's a pressing issue, I'm visiting my family this weekend. Most Ghost work is done in my weekends.. So if it's not necessary to finish this this week, I can't take it on 👪

[novaugust]

@ErisDS We do also have the option of informing the client of the pattern for building a post URL, and letting it compute things itself.
as far as "if someone updates the url pattern, all your links just broke until ember resets," well, shucks. The only real solution i see is websockets, but a heartbeat's always a thing too I suppose :)

[ErisDS]

We do also have the option of informing the client of the pattern for building a post URL, and letting it compute things itself.

I think this would result in quite a bit of duplicate logic. The solution of adding the pre-computed permalink to the post object is calling to me because it solves so many other problems and that makes me think it might be The Right Thing To Do (tm)

as far as "if someone updates the url pattern, all your links just broke until ember resets," well, shucks. The only real solution i see is websockets, but a heartbeat's always a thing too I suppose :)

Can't we just do store.unloadAll('post') whenever the setting is updated in the UI?

[novaugust]

Yeah, but dang! Reload all your posts because their url changed? Seems like
it'd be easier to just recompute the url ourselves

On Thu, Nov 6, 2014 at 4:06 PM, Hannah Wolfe notifications@github.com
wrote:

as far as "if someone updates the url pattern, all your links just broke
until ember resets," well, shucks. The only real solution i see is
websockets, but a heartbeat's always a thing too I suppose :)

Can't we just do store.unloadAll('post') whenever the setting is updated
in the UI?

—
Reply to this email directly or view it on GitHub
#4398 (comment).

[ErisDS]

Yeah, but dang! Reload all your posts because their url changed?

All of your posts' URLs just changed! That's kind of a big deal ;) It's not a setting I expect people to change very often.

[novaugust]

Touche.

On Thu, Nov 6, 2014 at 4:48 PM, Hannah Wolfe notifications@github.com
wrote:

Yeah, but dang! Reload all your posts because their url changed?

All of your posts' URLs just changed. That's kind of a big deal ;) It's
not a setting I expect people to change very often.

—
Reply to this email directly or view it on GitHub
#4398 (comment).

[sebgie]

We already do a similar override to the toJSON function in the user model in order to remove the password hash from the response, we could do the same to add a property to posts.

I think this is the best way to handle the URL problem atm 👍 ... Public preview deserves a new issue :).

[ErisDS]

I've raised #4445 to get the URL added to the post object which will unblock this issue. Preview links can be dealt with separately, I'm currently investigating how this is done elsewhere and will raise an issue with my findings when I'm done.

In the meantime @cobbspur you could update this PR to only show the link for published posts and to assume you have a url field ;)