#28125 closed enhancement (fixed)
youtube oembed for playlist link
Reported by: | alexufo | Owned by: | wonderboymusic |
---|---|---|---|
Milestone: | 4.0 | Priority: | normal |
Severity: | normal | Version: | 3.9 |
Component: | Embeds | Keywords: | |
Focuses: | Cc: |
Description
i think better add youtube playlist for auto embeding.
http://www.youtube.com/playlist?list=PL6BCB25412319E08A
This code must add to class-oembed.php providers. I think playlist id lenth is 18.
'#http:\/\/(www\.)?youtube\.com\/playlist\?list=.{18}#i' => array( 'http://www.youtube.com/oembed', true ),
and... why "/" are not escaping in class-oembed.php providers?
Change History (8)
#2
@
10 years ago
- Owner set to wonderboymusic
- Resolution set to fixed
- Status changed from new to closed
#3
@
10 years ago
and... why "/" are not escaping in class-oembed.php providers?
It only needs escaping if it's used as a delimiter in the same expression. We use #
as a delimiter here.
#4
follow-up:
↓ 6
@
10 years ago
Has anybody considered, that every time we change the regex/pattern in any of the existing items in the oEmbed providers list, we're breaking backwards compatibility for sites that use wp_oembed_remove_provider()
, for example to disallow YouTube embeds?
#6
in reply to:
↑ 4
@
10 years ago
Replying to kovshenin:
Has anybody considered, that every time we change the regex/pattern in any of the existing items in the oEmbed providers list, we're breaking backwards compatibility for sites that use
wp_oembed_remove_provider()
, for example to disallow YouTube embeds?
I've not considered this. I'm OK with [28593] but I wouldn't consider this precedent-setting. We've changed patterns before and probably will have a need to in the future.
#7
follow-up:
↓ 8
@
10 years ago
Re r28593, I wasn't implying that every new variation/addition to an embed handler should be a regex of its own, that's actually worse, because the regex engine now has to parse, cache and execute four expressions instead of two. The reason I asked about backwards compatibility is whether perhaps we should be looking at keying the list by a unique handle instead of a regular expression.
In 28552: