I think for auto-tiny urls it's best to offer something like:
Site.com/go/hash
Where hash would be a letter indicating content type (t for topic?) and the Id encoded to take less space (base64-like).
That would enable plugins to add more content types, too.
Yeah that sounds like a good idea... If I understand correctly, Starting the hash off with T for topic then hash for unique ID.
This can be installed in any directory and will give the short URL stating that directory.
So having like site.com/go/T-774h would suit, if I got it right lol.
Yay another URL shortener.
If you're planning to offer something whereby sites can generate their own shortened URLs that don't rely on l-url.com (so that site.com makes site.com/go/hash automatically), you're going to have *SO* much fun with all the mutant configurations out there that won't support your routing scheme properly, especially given how hard it is to actually set up site.com/go/hash instead of site.com/go.php?hash...
Well done for quoting my post but missing my point. It won't work on 'all' webserver as you quote.
Feel free to correct me then on why?Quote from Arantor on April 16th, 2012, 08:18 PM Well done for quoting my post but missing my point. It won't work on 'all' webserver as you quote.
Because IIS (without special configuration) and some configurations of Apache will not work the way you expect them to.Quote from oOo--STAR--oOo on April 16th, 2012, 08:23 PM Feel free to correct me then on why?Quote from Arantor on April 16th, 2012, 08:18 PM Well done for quoting my post but missing my point. It won't work on 'all' webserver as you quote.
I know that, but there are circumstances where the incorrect query string won't be passed to PHP properly at all on those servers.
It's an interesting concept but I'm not sure plugins will behave cleanly with it, I suspect unless it's managed pretty much automatically they won't use it.
Mind you, most plugins will only use PURLs features that are managed automatically (very few plugins for SMF ever cared, and those that did, were pretty much portals and/or PURLs type plugins in the first place), so if it can be done transparently and 'just work', plugins can use it but otherwise they probably won't.
I can't really understand all this interest on URL shorteners.. You still won't remember something like g.co/hyT&tR SO WHY CHANGE THE URL??
1. There's no benefit in memorabilty
2. Your link relies on a 3rd party server (if they change their URLs structure OR their server goes down OR their company fails OR for whatever reason the link doesn't work there's nothing you can do
3. Loading is slower (also if it's the speedest server on earth the loading will be slower than the original link because of the redirection)..
In short: I can't find a reason for an external url shortner to exist. For internal... dunno.. I'm ok with PURLs.. :P
I mean if you have boards/sub boards and long topic names, it could be convenient.
WIll the shortlink can be linked to specific post? maybe something like example.com/go/thash#postnumber
domain.com/go/b#1 is shorter than domain.com/index.php?board=1 yes (but it requires rewrites and you can't get around that)
But you've all missed the point I went at great lengths to try and explain. I got the fact that it would be an automatic thing, but if you make it a plugin, you have to either side-swipe other plugins and rewrite all their URLs (on top of the code in Wedge itself), or you have to expect the plugins to support it through choice. The former requires a lot of work, and the latter just isn't going to happen.
Now, let's say for the sake of argument that you make it core, presumably in addition to Pretty URLs. Not only, then, do you have to spend more time testing it, it makes it harder for plugin authors to work with, because there's three schemes instead of two that they have to contend with. I don't even see authors making real use of PURLs as it is, let alone having to navigate multiple schemes of URL routing.
I don't see where there's a problem with it...?
For putting this in core, I'm not sure why this is useful as compared to having Pretty URLs in core, but maybe that's just me
If you're creating short hashes that include t or b as references to topics and boards, that's fine - but how does that work for plugins?
What hoops do plugins have to go through in order to work? Plugins will naturally just fall in with pretty URLs (e.g. domain.com/do/pluginaction) without any work, and if they want to use pretty URLs, they can declare extra filters, but even that is going to be more effort than it's usually worth, so they won't bother.
If you not expect them to have to work with yet another URL routing scheme (optionally or otherwise), it's just more hassle for plugin authors, especially when people will ask them how to make it work.
Except that they don't have to use that scheme at all...
I mean you can spare one IF statement right?
You make it sound really complicated.To me it sounds like an easy process to do this.
I spoken to you a few times, over at SMF when i required help and you always get a lil hot headed.. Chill man.
Passes a spliff :P
STAR are you a karma guy or something similar..? :P