Make WordPress Core

Opened 13 years ago

Closed 11 years ago

Last modified 11 years ago

#18719 closed defect (bug) (fixed)

YouTube Embedding Fails for https:// URLs

Reported by: macmacken's profile MacMacken Owned by:
Milestone: 3.5 Priority: normal
Severity: normal Version: 3.2.1
Component: Embeds Keywords: has-patch
Focuses: Cc:


YouTube embedding in WordPress works only for http:// URLs. It fails for https:// URLs, i.e., the URL is shown and not the video that should have been embedded.

Attachments (2)

18719.diff (1.1 KB) - added by Otto42 12 years ago.
Properly support https URLs for youtube oembeds
18719.2.diff (1.3 KB) - added by Otto42 11 years ago.
patch to fix https youtube oembed calls

Download all attachments as: .zip

Change History (27)

#1 @ocean90
13 years ago

Does the Google API return a https embed code?

#2 @ocean90
13 years ago will be the same result as with http://. will only return the thumbnail_url with https://.

#3 @nacin
13 years ago

We may need to modify the get_html() method in WP_oEmbed to replace http:// with https?:// before sending it into the preg_match (but after preg_quoting). I don't see a problem with allowing oembed for any https URL when we have the http one registered.

#4 @ocean90
13 years ago

If I insert a https URL I would expect that I get a https output. But we can't guarantee it.

#5 @Otto42
12 years ago

This appears to have been fixed by youtube.

This URL gives me the html (an iframe). However, the src of that iframe is not an https URL, just an HTTP one. Don't know if an embedded iframe with a non-ssl link will cause an issue on pages.

#6 @rich_brat
12 years ago

  • Version changed from 3.2.1 to 3.3.1

Is there any way to get around this bug until it's fixed? I tried to add an https youtube provider using wp_oembed_add_provider but it didn't seem to work.

#7 @Otto42
12 years ago

Until YouTube returns https results in the iframe, embedding such a link would just result in a broken page in most browsers, since the iframe isn't SSL.

This is fundamentally a YouTube issue that they need to correct with their oembed, I think.

#8 @SergeyBiryukov
12 years ago

  • Version changed from 3.3.1 to 3.2.1

Version number indicates when the bug was initially introduced/reported.

#9 @rich_brat
12 years ago

Sorry, I'm new here :)

Thanks Otto42!

#10 @Otto42
12 years ago

In theory, simply adding these lines to class-oembed.php would do the trick:

'#https://(www\.)?*#i'         => array( '',            true  ),
'*'                             => array( '',            false ),

But there are two problems:

  1. The wp_remote_get in the _fetch_with_format function doesn't disable the sslverify option. So unless you have fully updated Certificate Authority lists in your PHP install (which no realistic PHP install has), then the SSL GET call will fail here. Adding with 'sslverify'=>0 as the arg array to this call will bypass this problem, but more code might be needed to check that an SSL transport is available before making the call.
  1. YouTube still doesn't return https src's in the iframes even when you use SSL throughout the request. So the resulting iframe will be http, potentially breaking the "secure" page in some browsers, if the page this is being embedded on is https as well.

So the patch is easy, however it's pointless to even bother with until YouTube fixes issue 2 and returns HTTPS src's in their oembed results.

When the iframe in the data returned from this link has an https src, then this patch can be made and be meaningful:

Last edited 12 years ago by Otto42 (previous) (diff)

12 years ago

Properly support https URLs for youtube oembeds

#11 @Otto42
12 years ago

  • Keywords has-patch added
  • Severity changed from minor to normal

Scratch that. It appears Google/YouTube decided that they didn't want to fix this in the most obvious way. Instead, they added a nonstandard "scheme=https" parameter for those cases where you want https results instead.


Attached patch will add the scheme=https parameter to the youtube call for the https cases, resulting in the iframe having the proper https src result. Tested on trunk, works fine. No special cases needed for https calls or SSL transport handling, the oembed call is still http, it's just the result that's being adjusted to have the https.

#12 @rich_brat
12 years ago

Great! I actually found that google thread but didn't really know what to do with it :)

A quick fix for functions.php:

wp_oembed_add_provider('*', '', false );
wp_oembed_add_provider('#https://(www\.)?*#i', '', true);
Last edited 12 years ago by Otto42 (previous) (diff)

#13 @tech163
12 years ago

I think it would make more sense to display HTTPS depending on if the blog is displayed via HTTPS, not if the link starts with https.

#15 @Mamaduka
12 years ago

  • Cc georgemamadashvili@… added

#16 @nacin
12 years ago

  • Milestone changed from Awaiting Review to 3.5

#17 @helenyhou
12 years ago

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

#18 @abstraction
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

The attachment added by Otto42 does not work. I tested it with this https link:
And it only displayed the link itself, not the embed. Also, the functions.php solution posted does not work either. Is there actually a solution out there that works?

EDIT: Further testings shows that this part of the URL is what is causing it to not function: &feature=g-u-u

The link still works fine in http but not in https when this is included. Any fix for this issue?

Last edited 11 years ago by abstraction (previous) (diff)

#19 @ocean90
11 years ago

Are you using any WordPress 3.5 version?

#20 @Otto42
11 years ago

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

Nope, patch does work. Tested on trunk, using your URL.

It doesn't actually matter whether the &feature= bit is included or not, because the link is retrieved and the oembed information is gathered directly from the linked site. WordPress isn't parsing the URL, it's retrieving it and getting the application/json+oembed link in the header.

Edit: Note that the oembed retrieval happens on post save, so editing the post and resaving will cause it to go do the retrieval again, so if it failed the first time for whatever reason, then editing and saving may produce the illusion that the edit made the difference, when really the save just made it retry.

Last edited 11 years ago by Otto42 (previous) (diff)

#21 @abstraction
11 years ago

@Otto42 You are correct. I tested this by clicking on the Preview button before it was saved. Is there any way to it work on preview prior to the post being published.

The issue here is that I run a multiple author platform where users publish for approval - meaning that they will need to submit it for approval before the YouTube embed will become functional...

Also to note, somehow this URL works in preview prior to save. But once &feature=g-u-u is added, it doesn't.

#22 @Otto42
11 years ago

That might be TinyMCE doing some magic tricks, separate from the oembed. The oembed may be improved in the future, but that's for a separate ticket.

11 years ago

patch to fix https youtube oembed calls

#23 @Otto42
11 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Update: This is still not correctly fixed. Although the https URL is supported, and the resulting oembed call returns the correct iframe embed, it also causes the iframe to be returned with only http content, not https content.

Again, YouTube added a non-standard parameter to support https versions of their oembeds, and that has to be handled separately.

18719.2.diff​ attached for trunk.

#24 @nacin
11 years ago

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

As this ticket was closed as fixed on a completed milestone, please open a new ticket.

Note that [21915] was "by design." It was intended to ensure we parsed https links, not to ensure https content. There was an IRC conversation about this:

#25 @Otto42
11 years ago

Fair enough.


Note: See TracTickets for help on using tickets.