Shorten share links

(Abhishek Gupta) #1

Continuing the discussion from So, you want to help out with Discourse:

Okay, Done.

Already send a pull request.I would appreciate if someone try it on production environment, as i am concerned with some performance issues, i.e the links are converted to links at the time of rendering the post menu, so if a page contains HUGE no of posts it may take some time for such large amount of POST requests. Because i don’t have a SSD yet, i can’t really tell if the time lag is because of code or my hardware :stuck_out_tongue: .

And Yay, my first contribution to discourse :smiley:

Topic shortlinks (bitly?)
(Jeff Atwood) #2

The shortening should only be triggered when you click the share (link) button. You definitely don’t want to do it earlier than that.

(Bill Ayakatubby) #3

What about storing the shortened URL along with the post ID so you only have to talk to the URL service a max of once per post? Maybe that wouldn’t work, because of ?u=<username>. Unless that part weren’t passed to the service and just tacked onto the short URL? But then that starts to defeat the purpose of shortening the URL in the first place.

(Jonathan Allard) #4

I appreciate the thought as I think URLs a a bit long as well, but I’m not too fond of the “obfuscation” a shortener does with the URL: instead of seeing useful information like “it’s from a forum”, and “it’s a thread, and it’s number 1234”, you just see “this is an URL”.

If I take a look at the URL of Bhael’s post above me:

It is 67 chars long. It includes: forum host, thread type, title, id, reply, and referring user.

What if we cut out the title and the referring user? The title is redundant, and the referrer is just a nice extra.

36 chars long. (Of which 26 is scheme + host) The path would be shortened from 41 to 10.

While I appreciate the thought, I don’t like the implementation. Or should we make everyone happy and make it a site setting? *nervously checks if there’s already one* phew.

(Jeff Atwood) #5

You can already do this but the slug has to be there in at least one character form:

That is only 2 chars off your example, above.

(Interestingly @eviltrout if I enter the slug as // I get a blank page.)

(Abhishek Gupta) #6

But that would lead to awfull time lag between you clicking the share button and the view actually showing.

So you have to do it before rendering the view anyways.

(Jeff Atwood) #7

Slowing down the page for every logged in user, just because a few people might want to share shortened URLs, is not a good design choice. Better to just show a spinner when you click share. Google is generally quite fast.

(you could also cache the results, so only the first person to click share pays the cost of calling to retrieve the shortened URL. And if nobody ever clicks share… why do work you don’t have to?)

(Kane York) #8

Hmmm… I’ve been abusing the “share” links to get the RAW text of a post. This would be hampered by shortening :stuck_out_tongue:
turns into ← still works, despite the ?u=riking at the end.

(Abhishek Gupta) #9

You can still get the longUrl back from api, but i guess that will be too much of unecessary pain, i think i can update my commit so as to leave the data-share-url attribute in the share button (use inspect element on share button) as it is and shortening the url in share_view.js and not in post_menu_view.js .

yes, i was also “expecting” google to have fast replies but “not so fast” , it really depends on one’s internet connection. and good idea!, I will look into caching them, but i m lost as to how to show spinner, Anyone help on that? ,

I dont think that it is possible, as the ?u=<username> make each share url different so it will be cached for him only. click once he clicked share, he waits then he can click on it as many times he want.

@codinghorror will it be good if i shorten urls removing the ?u=<username> at the end?, this way we could cache the urls once they are shortened.

(Robin Ward) #10

This happens because it trips up the router. I am not sure if having two slashes in a row is even a valid URL?

(Kane York) #11

Yeah, it’s valid. There’s also supposed to be a difference between “two slashes” and “3+ slashes”, because of backwards compatibility with UNC (which used \\HOSTNAME\file).

(Jeff Atwood) #12

Low priority but should not end up on a blank page regardless.

(Volkan Unsal) #13

Is there a way of making the short form of the url default in the share menu?

(Paul) #14


How hard is it to add custom domain short url service? If possible please add those in the setting in upcoming update version.


(Graham Perrin) #15

Trivia: with Firefox 49 on TrueOS Desktop I found that omitting a slug e.g. Shorten share links causes an access error if simply clicked, but does work (does expand) if the excessively shortened link is opened in a new tab.