Opened 5 months ago
Last modified 7 weeks ago
#23149 new enhancement
YouTube Embedding is incorrect for https:// URLs
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | Awaiting Review |
| Component: | Embeds | Version: | 3.5 |
| Severity: | normal | Keywords: | |
| Cc: | JayCC |
Description
Reference: #18719, #20102, Conversation from 9-19-2012:
https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012-09-19&sort=asc#m459455
This is incorrect and a bug. If the user has posted an https link, then we should send the correct parameters to YouTube to get an https value in the resulting HTML returned.
At present, there is no way within WordPress to get the proper https code in a YouTube oEmbed iframe when https is actually desired.
Attachments (1)
Change History (8)
I disagree. One would expect an obvious behavior, the code does not have that expected behavior. Therefore, it's a bug.
- I agree that the spec sucks. YouTube has specifically created a scheme parameter workaround because of this. There is no reason to not to use it.
- It is perfectly acceptable to put https content into an http page, and this is not typically considered to be "mixed content". The reverse of putting http into https pages, however, generates mixed content warnings, and that is indeed a problem. So basically, you're saying here that we should not support the case which is an actual problem because the totally-not-a-real-problem case is more common?
- The core does not need any https front end logic baked in for it to do the right thing for oembed when it is explicitly given an https URL.
I'm with Otto here.
This fix does prevent annoying mixed content warnings on https pages, that basically make the YouTube oEmbed unusable on https sites at this time.
There's no problem to embed a video as https on an http page, so this doesn't do harm. No one will notice. Someone who enters a https URL but then doesn't want or expect https to be embedded is doing it wrong.
I don't care, if it's labeled bug or enhancement, but I'd also like to see this fixed.
I also need https return if I am using https link. I have posted about this in a support thread.
Either fix it in core, or give us a function or switch, so we could force WordPress to return with https, maybe via condition in function.php
FWIW, we've tested this patch in our development environment with much success, and will be deploying it to production soon. +1 to have it added to core (don't care much if it's classified as a bug or feature).

Incorrect? Eye of the beholder. A bug? No, this looks like an enhancement.