Opened 5 months ago

Last modified 7 weeks ago

#23149 new enhancement

YouTube Embedding is incorrect for https:// URLs

Reported by: Otto42 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)

23149.diff (1.3 KB) - added by Otto42 5 months ago.

Download all attachments as: .zip

Change History (8)

Otto425 months ago

  • Type changed from defect (bug) to enhancement

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

  1. The oEmbed spec is oblivious when it comes to https content.
  1. Mixed content would still occur when someone uses an https link but doesn't actually want or expect https content. This, I imagine, is far more common than someone with frontend https who does want https content.
  1. Core does not currently have any frontend https logic baked in.

I disagree. One would expect an obvious behavior, the code does not have that expected behavior. Therefore, it's a bug.

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

  • Cc JayCC added

+1 on this in core, and +1 on it being a bug. It doesn't matter much whether it's extra on top of the oEmbed protocol, since it causes broken behaviour on the frontend regardless. Given how trivial the patch is, it's irrelevant anyway.

Note: See TracTickets for help on using tickets.