Support "shortlink" URL shortening

[samj]

Wordpress.com just announced support ([en.blog.wordpress.com/2009/08/14/shorten/]) for the creation of short links and the advertising of those links in both the HTTP Link: header and the HTML LINK element. This allows interested clients to auto-discover the short link, thus avoiding having to manufacture their own via a third party service (e.g. tinyurl.com, bit.ly).

There are many benefits to this approach including giving the webmaster control, giving the user a hint as to the contents (short links are currently almost always opaque), improving client performance, avoiding linkrot, etc.

For more information refer to ​http://purl.org/net/shortlink

[samj]

UML Sequence Diagram

[samj]

The link to the Wordpress.com announcement is ​http://en.blog.wordpress.com/2009/08/14/shorten/

[miqrogroove]

samj, I hope you're not implying that WordPress would only support wp.me short links? The implication (although you didn't say it explicitly) seems to be that WordPress will be capable of hosting short links on any domain?

That leads me to another point, which is that some people use long domain or subdomain names. To pull this off properly WordPress will need a native cross-domain forwarder that can be installed on a 2nd-level domain instead of www. or blog.

[miqrogroove]

I think it's a good idea for SEO in general, to link to one's own domain when needed. I'm in favor of adding it ASAP.

[dd32]

I'm closing as wontfix and leaving it for plugin territory.

As of WordPress 2.9+, If you have the WP.com stats plugin installed, You get a shortlink added automatically based off the wp.me system.

Core shouldnt prefer any specific shortening service over one another.. just look at the twitter & bit.ly combination..

Users have the option to use a Plugin to get the wp.me domain shortlinks if they wish, and theres nothing stopping a plugin from using bit.ly or tiny.cc etc.

[caesarsgrunt]

Agree that there shouldn't be core support for a favoured service.

Were there a standard API core support could be included with an option to enter the URL of the service you want to use; but as there isn't we can't do that yet.

[caesarsgrunt]

Would be nice if Automattic were to release a plugin specifically for wp.me without having to use WP Stats, though.

[miqrogroove]

Guys, the whole point of this ticket was, "avoiding having to manufacture their own via a third party". In other words, adding the service to core, not relying on any other service.

Please give this idea a fair chance as it's already +4.

[Denis-de-Bernardy]

I've voting -1, myself. I think this should be handled by a plugin.

[dd32]

In other words, adding the service to core, not relying on any other service.

And who do you suggest? wp.me? If so, dev-feedback seeking input from rboren or matt or whoever runs wp.me for thoughts on inclusion into core - Personally i'm thinking of seperation of the Automattic stuff, and the Open source application.

I stand by my reasoning however, Its possible to avoid everything by inclusion into core, Some things are better left to plugin material only however.

[miqrogroove]

Haha, I think you guys are still missing the original point, which is to NOT RELY ON A THIRD PARTY.

It might even be adequate to advertise the existing "guid" forwarder. For example, ​http://blogyul.miqrogroove.com/?p=5679 isn't the shortest URL in the world, but it saves over 60 characters and already provides canonical redirect.

[dd32]

Haha, I think you guys are still missing the original point, which is to NOT RELY ON A THIRD PARTY.

Sorry, I didnt see you mention that up there the possibility for WordPress to offer them internally

Yes, It would be entirely possible to use the non-rewritten url's for a "short link" - which is not what the OP was requesting from what i can tell.

[miqrogroove]

OP was a bit ambiguous. He was speaking abstractly about the advertising protocol, "allows interested clients to auto-discover the short link", and "giving the user a hint as to the contents", in other words by showing the destination domain instead of some meaningless 4-char brand.

[demetris]

It might even be adequate to advertise the existing "guid" forwarder. For example, ​http://blogyul.miqrogroove.com/?p=5679 isn't the shortest URL in the world, but it saves over 60 characters and already provides canonical redirect.

I have three objections:

First, there is not demand for such a short URL.

Second, the WP document HEAD has already more than enough stuff in it as it is.

Third, it is very easy to do with a plugin.

Consequently, I suggest WONTFIX.

(There is a probable fourth objection as well: the guid forwarder is not supposed to be used like this. It is supposed to change, e.g. when you switch to another platform. The permanent URL is supposed to be the prettified permalink.)

[miqrogroove]

First, there is not demand for such a short URL.

LOL I beg to differ.

I have a plugin finished now. It's similar to the one on Google Code but doesn't implement the bells and whistles for custom slugs. I'll put a zip file at ​http://blogyul.miqrogroove.com/about/

[miqrogroove]

Third, it is very easy to do with a plugin.

It's just as easy to do it in core?

I think the best argument against putting this in core is that it doesn't cover hierarchical category pages. So, if I want a shortlink for myblog/category/cat1/subcat2/long-annoying-subcat3/ then the guid forwarding is no use. There would have to be a redirection table, which I would agree is outside the scope of a blog core.

[demetris]

@miqrogroove:

Considering how easy this is to put together as a plugin, if there was demand I suppose there would be plugins already for it and they would be popular.

(I’m talking about the ​http://example.com/?p=123 solution, of course, not about fancy stuff.)

But probably I’m wrong and you’ll become famous with minimal effort. :-D

[miqrogroove]

Considering how easy this is to put together as a plugin

And mine is certainly not the first, but probably the simplest. What I'd like everyone to consider is that the bells and whistles, things like custom slugs, external links, widgets, hit counting, 3rd-party options, those can and should all be in the domain of themes and plugins. But shouldn't they all have a common hook to build on?

[westi]

I don't think we should introduce a set of simple function(s) which provide generic shortlink functionality.

By default these functions would not provide shortlinks but they would have the hooks in place such that any shortlink plugin could use them.

That way which ever one you installed it would get the same frontend/admin experience and themes could be written to support it.

[miqrogroove]

Second, the WP document HEAD has already more than enough stuff in it as it is.

Might be appropriate? if ('HEAD' != $_SERVER['REQUEST_METHOD']) { header(...

[janeforshort]

-1. I'm with Denis, dd32, etc: plugin territory. wp.me is an Automattic service, so keeping out of core is necessary to prevent built-in service bias. Putting in something that would support choosing any service wouldn't have the bias, but I doubt it would be a top request for the majority of (our millions of worldwide) users, so on that count it doesn't belong in core, but in a plugin. Putting in code to create a short URL from your own domain name seems unevenly useful... the whole point of shorteners is to get the minimum number of characters possible, but if my blog is at anawesomebutlongishdomain.com, shortening the path without shortening the domain name wouldn't help enough in the keep-it-under-140 effort.

So I vote plugin, and if the plugins that address it become popular enough, we could consider a core plugin for it. Most core feature proposals have to prove themselves by achieving popularity as a plugin first; why should this one be different?

[Denis-de-Bernardy]

@Jane: after re-reading the thread, I think the following *could* be an option:

function get_the_short_link($id = null) {
  // 1. use current post $id if none is supplied, as we do for permalinks

  // 2. fetch short_link, i.e. domain.com/?p=123 or /?page_id=456 or...
  
  return apply_filters('the_short_link', $short_link, $id);
}

function the_short_link($id = null) {
  $short_link = get_the_shortlink($id);
  if ( $short_link )
    echo '<link rel="shortlink" href="' . esc_url($short_link) . '" />';
}

and perhaps another function to send the needed header.

in other words, the default would be that non-fancy permalinks are shortlinks in their own right (which they are), and WP would expose an API that plugins can use so they don't interfere with each other in the event that several such plugins are active.

[miqrogroove]

I named my machine-readable output shortlink_http() and shortlink_html() and then added a human-readable template tag called the_shortlink(). So, my version now has 4 functions total.

[miqrogroove]

I'm starting to wonder if 301 would be more appropriate than 302 for ID queries?

[miqrogroove]

I don't really stay on top of the Twitter fad, so I found this to be very interesting:

​http://help.twitter.com/forums/10713/entries/88340

[miqrogroove]

the best argument against putting this in core is that it doesn't cover hierarchical category pages

It just occurred to me that WP_Query already supports this. I'll slap a couple extra if statements onto the dev version of the plugin and take it for a test drive.

[miqrogroove]

Having bad luck with tags, as it seems tag_id is broken. Made a new ticket at #11711

[miqrogroove]

I'm seeing an unintended benefit from production testing. Google seems to have increased the ranking of attachments (gallery pages) and is displaying the shortlinks in search results.

In other words, blog/yyyy/mm/post-name-slug/omg-long-attachment-filename-slug/ rarely ever ranked but is now showing up in search results as blog/?p=nnnn

[miqrogroove]

Also noteworthy: Slurp and Baiduspider are the only agents that recognize the machine-readable links specified by OP. Google is definitely using the human-readable variety that I added to the plugin.

[miqrogroove]

I believe there's a 3.0 feature freeze just around the corner, so can we help give samj a yes/no answer to his feature request?

The latest version of my plugin provides automatic shortlinks on posts, attachments, pages, and categories. Shortlinks for tags are disabled in my plugin, but I added comments in each function where it could be supported given a custom/future redirection system.

This framework also includes two template tags for human-readable links, which were found to be preferred by Google. The need for a second tag arises in distinguishing between singular and loop type objects (category page vs. each post's category) in templates, which had not been a concern in the headers-only protocol.

I'm open to ideas about making my plugin more abstract, if that helps.

[ryan]

Core WP should simply provide a framework that functions can plug into. Patch introduces wp_get_shortlink(). By default it returns an empty string for all shortlink requests. It is up to plugins to hook in and provide the shortlinks. If the shortlink is not empty then WP sends the shortlink header and link tag unless the plugin specifically turns that off by removing the actions.

[matt]

Could it by-default return the p=123 style?

[ryan]

Sounds good. And we can build the Get Shortlink button into the edit form UI.

[westi]

This looks good to me.

I like the idea of the simple ?p= based shortlinks and the ease of plugin override this offers

10640.diff == dev-reviewed

[ryan]

(In [13635]) wp_get_shortlink() and pluggable shortlink generation. fixes #10640

[Viper007Bond]

Docs need to be updated. They still say it does nothing unless a plugin is installed or whatever.

[ryan]

Returning p= shortlinks by default causes shortlink headers to be sent for posts. This could conflict with existing shortlink plugins. If no shortlink is returned by default then no headers are ever sent unless a plugin explicitly starts using the shortlink API. Is potential conflict with existing shortlink plugins a big enough deal to turn off post defaults in core?

[nacin]

Is potential conflict with existing shortlink plugins a big enough deal to turn off post defaults in core?

If we hook into wp_shortlink_header at the highest priority, then any plugin sending a shortlink header will override the default one.

[miqrogroove]

Nice speedy work, guys. Be sure to look at the examples in Simple Short Links. The default arguments for header() are usually not appropriate for Link: headers. I suggest double checking that. Also consider my earlier point about having a template function. The human-clickable/copyable short links have been vastly more successful than the protocol links.

"The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type. By default it will replace, but if you pass in FALSE as the second argument you can force multiple headers of the same type."

[miqrogroove]

see also [13650]

[miqrogroove]

Oh, now I remember the other point:

'wp' is the wrong hook for shortlinks. I've been using 'template_redirect' priority 11 to ensure the shortlinks aren't applied to the wrong URL (caused by canonical.php).

[miqrogroove]

Fix the actions.

[miqrogroove]

See also [13652]

[miqrogroove]

It's not crucial, but I'll also propose that the if ( !empty($post_id) ) should also include a check on whether pretty permalinks are enabled.

[miqrogroove]

@todo before close:

1. Check for permalink config at the if (!empty($post_ID)) line.

2. Add the missing linefeed to the end of the XHTML header.

3. Copy template tag function the_permalink() from Simple Short Links. It may be desirable to add $before and $after args because the core shortlink generator doesn't always return a link.

[miqrogroove]

Whipped this up during the IRC meeting. Patch is not tested.

[miqrogroove]

10640.4.diff tested with and without uglinks. Works great :)

[ryan]

[13683]

[sirzooro]

HTML attributes needs escaping. Also I would like to have new filter the_shortlink to modify link (e.g. to add nofollow attribute). Attached patch does this.

[sirzooro]

OK, I see that function expects that title is already sanitized. So I am attaching another patch - this one also adds some spaces to match our coding standard.

[sirzooro]

Escape only href attr, whitespace corrections

[miqrogroove]

Well, wp_shortlink_wp_head() needs to be escaped the same as the_shortlink() for this to make sense.

[sirzooro]

Added escaping to wp_shortlink_wp_head() too

[markmcwilliams]

Do we just need that latest patch committed, then we're good to close the ticket?

[miqrogroove]

13693.3.diff does no harm, but I'm not convinced there's any need for it. That patch still assumes the link generator has provided a well-formed UTF8 URL, which is not validated in any way. I am not bothered by the further assumption that the link generator isn't going to inject quotes, ampersands, angle brackets, and the like during URL shortening.

[westi]

I think we should both be escaping the url suitably for output in the body and in the header on top of the current patch.

[westi]

(In [14207]) Added escaping to wp_shortlink_wp_head() too. See #10640 props sirzooro.

[westi]

(In [14208]) Switch to using esc_url{_raw} for the shortlink output as it is a url not just any attribute. Fixes #10640.