Insert link client side instead of parsing @syntax server-side

[ewinslow]

Pros:

• Author can modify link text
• Can mention any other entity on the site, not just users
• Less server-side parsing required
  • performance benefit
  • Issues #17 and #12 go away automatically
• <a> tags are part of a standard. @mentions are not.
• We already need to solve the broken-link problem, so this just makes it easier for people to link to things.
• There's a handy library for it ( https://github.com/ichord/At.js )

Cons:

• Links break. Server-side parsing means they could be kept up-to-date or auto-removed.
• ECML could give us the best of both worlds

NB: I say "instead of" but that just means going forward. We'd still need to support server-side @mention for BC, I'm sure.

Votes

In favor of storing the full link to the mentioned entity (<a href>...</a>):

• Evan
• Steve

In favor of just storing @mention:

• Juho
• Matt

[mrclay]

What would be the rules to determine who gets notified? Wherever we recognize a profile link?

[mrclay]

I like the simplicity, and a site could determine the link text format. E.g. @Full Name instead of @username.

[juho-jaakkola]

I don't like hard-coded links in content because they cause trouble e.g. when the domain changes or site is switched from http to https.

[hypeJunction]

Ideally we would use ecml for this. A bit of each world, user can control the text and styling client side, while the @syntax is parsed server side

[ewinslow]

@mrclay Yes, we'd parse the link and determine if it points to a user entity and then notify that user they've been mentioned. Note that we should be doing this already -- this happens on the community all the time because people manually include links to other users. This feature just would make that much easier.

@hypeJunction My ideal is actually that we would NOT use ECML for anything and stick to standards. Not sure if that's radical or whatever but I just have no interest in supporting a custom markup format. I do not think that's a good use of our time. Better to have support for oembed or something along those lines.

@juho-jaakkola Hard-coded links in content are a reality that isn't going to be solved by people using @mentions. People link to things other than users as well. It's a valid problem that we should come up with a solution to, but custom markup isn't that solution.

[mrclay]

I don't think we can ever get out of migrating URLs for webroot changes, so I see that problem as already handled. I like the idea of not having to process all views in RSS, exports, web services, excerpts, on and on.

[juho-jaakkola]

Lets vote. And If I find myself on the losing side, lets make it configurable via a setting. ;)

[ewinslow]

I started a vote.

[mrclay]

The vote options are confusing. I thought this ticket was basically between storing one of these representations:

@username vs. <a href="../profile/username">Any link text</a>

[ewinslow]

Clarified it.

[Wouter0100]

To get back in this discussion, I'm personally for saving the @mention to a DB, instead of a <a>. A mention is a mention, nothing more. The user shouldn't be able to mess around with it. Google+, Facebook and Github doesn't replace it with a <a> either (from the users perspective), just because it isn't user friendly, if you ask me.

It also takes a lot of problems if you have hard coded links in the DB, for example when you switch between domains or you get an SSL certificate.

What we could do is just store @mention, print that to the browser and let a JS script takes care of the @mention -to-<a> conversion on the clients side (over the whole site), instead of a server-side script. This if performance is really is a problem.

Or, we could get the ob_start and preg_match it (I'm unsure if there is a hook for that?)