URL shorteners ( redirects) should to be supported by the embed handling for couple of hops

[pbearne]

It should be possible to use URL shorteners ( redirects) to load embeds.

I have been testing the new embeds feature and have found that a Bit.ly link doesn't work, but the resolved link does

I believe we should support at least one hop if not two

[swissspidy]

Thanks for creating the ticket after our recent chat.

Currently, when pasting a URL like ​http://bit.ly/1Muwesb (a YouTube video), http://www.youtube.com/oembed?url=http://bit.ly/1Muwesb&format=json gets called in the end, which of course doesn't work. That's because WordPress follows the redirect to YouTube, but passes the original URL to the endpoint instead of the final redirect URL.

To make this work, we'd need to store the final redirect URL, which is currently not possible with the HTTP API. This means there needs to be an equivalent toWP_Http::handle_redirects that doesn't just redirect, but returns the final URL.

This would certainly make things more complex and I'm not sure if it's worth the effort and even the desired behaviour.

[pbearne]

I can see the problem.

How is the embed code going to know that ​http://bit.ly/1Muwesb is a youtube video short of having a white list of shorteners and then calling the URL in order to get the end URL when we when calling for the embed at that point. This would be a lot of traffic and we would have to do some caching to manage the load.

This would be nice maybe the answer would be to only follow URL's that are wrapped in an [embed] shortcode

I can not see this request going anywhere soon

Paul

[johnbillion]

Closing based on the above. It'll be a lot of effort for little gain.

[stephenharris]

@swissspidy I've come across this issue in another context. Do we actually need to store the final URL?

In the YouTube example above, and with WordPress, the discovered endpoint URL includes the ?url part, but WordPress over-writes it with the URL originally provided: ​https://github.com/WordPress/WordPress/blob/55c3fa0cb0637c85f89b225b3fde8d0256a9e463/wp-includes/class-oembed.php#L460

Is that line necessary? The oembed discovery documentation (​http://oembed.com/#section4) states that the provider is responsible for providing a full embed endpoint (including URL).

Removing that line will fix the issue for embedding redirected urls, and shouldn't impact other cases.

[swissspidy]

@stephenharris Good catch. However, the URL part is only there if it was found during oEmbed discovery, but not when wp_oembed_add_provider() is used for registering a provider. So yes, that line is necessary.

But we could try to extract any url param from the $provider variable and only use add_query_arg() if the url param isn't already there.

[stephenharris]

Ah, of course. Checking for an existing url query variable seems the best way forward. I've attached a patch with tests. Any thoughts?

[swissspidy]

Thanks, I'll have a look shortly. Looks good at first glance, but could use a few improvements.

[jorbin]

@swissspidy what improvements would you like to see on this patch?

[swissspidy]

In 34335.2.diff​:

• Correct @ticket annotation
• Use parse_url() with the PHP_URL_QUERY argument.
• Correctly declare $_provider_url in tests.
• Improve docs a bit.

[swissspidy]

One big problem with the current approach is is that when pasting the shortened URL to a YouTube video, WordPress will eventually embed it, but not detect that it's coming from a trusted provider. That means the embedded YouTube video won't work because of the security restrictions WordPress puts on the iframe.

That's because the URL passed to wp_filter_oembed_result() is still the shortened URL. The resolved URL gets lost in WP_oEmbed::fetch().