WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#10640 closed task (blessed) (fixed)

Support "shortlink" URL shortening

Reported by: samj Owned by:
Milestone: 3.0 Priority: normal
Severity: normal Version:
Component: General Keywords: dev-reviewed has-patch
Focuses: Cc:

Description

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

Attachments (8)

shortlink-uml-sequence.png (71.0 KB) - added by samj 6 years ago.
UML Sequence Diagram
10640.2.diff (2.7 KB) - added by ryan 5 years ago.
10640.diff (3.9 KB) - added by ryan 5 years ago.
10640.3.diff (962 bytes) - added by miqrogroove 5 years ago.
Fix the actions.
10640.4.diff (1.7 KB) - added by miqrogroove 5 years ago.
Whipped this up during the IRC meeting. Patch is not tested.
13693.diff (674 bytes) - added by sirzooro 5 years ago.
13693.2.diff (1.2 KB) - added by sirzooro 5 years ago.
Escape only href attr, whitespace corrections
13693.3.diff (1.6 KB) - added by sirzooro 5 years ago.
Added escaping to wp_shortlink_wp_head() too

Download all attachments as: .zip

Change History (67)

@samj6 years ago

UML Sequence Diagram

comment:1 @samj6 years ago

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

comment:2 @miqrogroove6 years ago

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.

comment:3 @miqrogroove6 years ago

  • Milestone changed from Unassigned to 3.0

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.

comment:4 @dd325 years ago

  • Milestone 3.0 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:5 @caesarsgrunt5 years ago

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.

comment:6 @caesarsgrunt5 years ago

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

comment:7 @miqrogroove5 years ago

  • Milestone set to 3.0
  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:8 @Denis-de-Bernardy5 years ago

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

comment:9 @dd325 years ago

  • Keywords dev-feedback added; shortlink shorturl removed

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.

comment:10 @dd325 years ago

  • Type changed from enhancement to feature request

comment:11 follow-up: @miqrogroove5 years ago

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.

comment:12 @dd325 years ago

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.

comment:13 @miqrogroove5 years ago

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.

comment:14 in reply to: ↑ 11 @demetris5 years ago

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.)

comment:15 @miqrogroove5 years ago

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/

comment:16 @miqrogroove5 years ago

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.

comment:17 @demetris5 years ago

@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

comment:18 @miqrogroove5 years ago

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?

comment:19 @westi5 years ago

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.

comment:20 @miqrogroove5 years ago

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(...

comment:21 @janeforshort5 years ago

-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?

comment:22 @Denis-de-Bernardy5 years ago

  • Keywords needs-patch added; dev-feedback removed

@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.

comment:23 @miqrogroove5 years ago

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.

comment:24 @miqrogroove5 years ago

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

comment:25 @miqrogroove5 years ago

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

comment:26 @miqrogroove5 years ago

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.

comment:27 @miqrogroove5 years ago

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

comment:28 @miqrogroove5 years ago

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

comment:29 @miqrogroove5 years ago

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.

comment:30 @miqrogroove5 years ago

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.

comment:31 @miqrogroove5 years ago

  • Keywords needs-patch removed
  • Milestone changed from 3.0 to Future Release

comment:32 @ryan5 years ago

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.

@ryan5 years ago

comment:33 @matt5 years ago

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

comment:34 @ryan5 years ago

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

@ryan5 years ago

comment:35 @ryan5 years ago

  • Milestone changed from Future Release to 3.0

comment:36 @westi5 years ago

  • Keywords dev-reviewed added

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

comment:37 @ryan5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

comment:38 @Viper007Bond5 years ago

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

comment:39 @ryan5 years ago

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?

comment:40 @nacin5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:41 @miqrogroove5 years ago

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."

comment:43 @miqrogroove5 years ago

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).

@miqrogroove5 years ago

Fix the actions.

comment:45 @miqrogroove5 years ago

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.

comment:46 @miqrogroove5 years ago

@todo before close:

  1. Check for permalink config at the if (!empty($post_ID)) line.
  1. Add the missing linefeed to the end of the XHTML header.
  1. 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.

@miqrogroove5 years ago

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

comment:47 @nacin5 years ago

  • Type changed from feature request to task (blessed)

comment:48 @miqrogroove5 years ago

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

comment:49 @ryan5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:50 @sirzooro5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

@sirzooro5 years ago

comment:51 @sirzooro5 years ago

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.

@sirzooro5 years ago

Escape only href attr, whitespace corrections

comment:52 @miqrogroove5 years ago

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

@sirzooro5 years ago

Added escaping to wp_shortlink_wp_head() too

comment:53 @sirzooro5 years ago

  • Cc sirzooro added

comment:54 @solarissmoke5 years ago

  • Cc solaris.smoke@… added

comment:55 @markmcwilliams5 years ago

  • Keywords has-patch added

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

comment:56 @miqrogroove5 years ago

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.

comment:57 @westi5 years ago

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.

comment:58 @westi5 years ago

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

comment:59 @westi5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.