Opened 15 years ago
Closed 15 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)
Change History (67)
#1
@
15 years ago
The link to the Wordpress.com announcement is http://en.blog.wordpress.com/2009/08/14/shorten/
#2
@
15 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.
#3
@
15 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.
#4
@
15 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.
#5
@
15 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.
#6
@
15 years ago
Would be nice if Automattic were to release a plugin specifically for wp.me without having to use WP Stats, though.
#7
@
15 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.
#9
@
15 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.
#11
follow-up:
↓ 14
@
15 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.
#12
@
15 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.
#13
@
15 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.
#14
in reply to:
↑ 11
@
15 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.)
#15
@
15 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/
#16
@
15 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.
#17
@
15 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
#18
@
15 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?
#19
@
15 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.
#20
@
15 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(...
#21
@
15 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?
#22
@
15 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.
#23
@
15 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.
#25
@
15 years ago
I don't really stay on top of the Twitter fad, so I found this to be very interesting:
#26
@
15 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.
#27
@
15 years ago
Having bad luck with tags, as it seems tag_id is broken. Made a new ticket at #11711
#28
@
15 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
#29
@
15 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.
#30
@
15 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.
#32
@
15 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.
#36
@
15 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
#38
@
15 years ago
Docs need to be updated. They still say it does nothing unless a plugin is installed or whatever.
#39
@
15 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?
#40
@
15 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.
#41
@
15 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."
#43
@
15 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).
#45
@
15 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.
#46
@
15 years ago
@todo before close:
- Check for permalink config at the if (!empty($post_ID)) line.
- Add the missing linefeed to the end of the XHTML header.
- 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.
#50
@
15 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.
#51
@
15 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.
#52
@
15 years ago
Well, wp_shortlink_wp_head() needs to be escaped the same as the_shortlink() for this to make sense.
#55
@
15 years ago
- Keywords has-patch added
Do we just need that latest patch committed, then we're good to close the ticket?
#56
@
15 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.
#57
@
15 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.
UML Sequence Diagram