If anyone else is not working on it, i would like to work on it, just to be clear, it should work like this right?
Topic shortlinks (bitly?)
Discourse Development Contribution Guidelines
Correct, it is tied to the “share” dialog you get to by pressing the link icon on post, or the “Share” button at the bottom of the post.
When that comes up, with your plugin active, it should contain the goo.gl URL rather than the raw native URL for the topic.
Does it needs to be a plugin?, it will way much easy to implement in core directly,just need to edit 2-3 files only, atm i can add in the core. is that any good?
And does this is also needed?
No, I definitely would not appreciate the forum software randomly shortening my links.
Just use the markdown syntax:
Also, the discussion of that should be moved to a new topic.
Love it! Could that be integrated by default meaning any URL cut and paste would auto-magically render to a nice short goog.le URL? Like an option that can be switched on and off but is on by default. Talk about giving your data a break good stuff.
If this feature is implemented, it definitely needs to be a plugin, and ideally the plugin should allow the admin to select the URL-shortening service to use. I, for one, would not choose Google’s service.
All of these solutions imply using a 3rd party link shortening service. Why using a 3rd party when the discourse app itself could have been used? This could be: yourdomain.com/t/foo123, where foo123 is the string id of the topic. I know this is not super shor like goo.gl, but it is much shorter than the title version.
This requires non-auto-incremental-integer ids for topics. Unlike mysql, postgres is not inefficient when it comes to non integer primary keys. But, rails was written to solve a specific problem: to work with mysql and integer primary keys. And whenever your problem gets deviated from the problem that rails was written to solve, all the magic of rails is replaced with a pile of pain.
Reddit, which is build on postgres, uses random string ids for looking up links. It would be nice to have the same url pattern for discourse.
Another downside of integer ids is that, it exposes some information about your app: I know exactly how many entities your app has.
I agree completely. I think this should be the default behavior. If using an external shortening service API is an added feature, that would be great. However, if it’s your own short URL, at least you know it will be up as long as you want it to be.
Because the odds of Google existing in 20 years are fairly high, whereas the odds of your particular Discourse forum existing … isn’t?
Basically, don’t break links. It’s bad enough that shortening happens at all, which breaks huge swaths of links when a “shortener” inevitably disappears… but the best you can do is rely on a very reliable shortener at the center of the Internet, aka. Google.
Choice is fine, but choosing to create your own “service” is a bad idea.
If your forum is down the point is moot anyway. Choosing one 3rd party over another is a debate regardless of how much faith one has in one particular company. I agree that Google shortening should be an option but bit.ly is still the service leader.
That’s why I would say offering a built in shortening options is the best route with the ability to use 3rd party APIs like bit.ly or whatever (maybe via plugins) second.
As I just asked elsewhere: is there an easy way to infer a short URL from the address bar, similar to the
/raw/nnn format? e.g.
/t/nnn? Did not work when I tried it, but it seems it should address this question of URL shorteners.
I understand the SEO reasons for having the post title in the URL, but for usability it would be nice to be able to get to it directly. I could then also create a shortening domain myself that forwards folks on to my forum URL, e.g.
kb2.org/t/nnn to send people to
discourse.kabissa.org/t/nnn and on to
well, that was quick. yet another hidden feature! loving the treasure hunt.
FWIW, what you were expecting to work may work in the future.
See also from 8 hrs ago, coincidentally: