[wp-trac] [WordPress Trac] #10337: Easier embeds for 2.9 (oEmbed perhaps?) (was: Bundle shortcodes for popular sites, services, and template tags.)

[WordPress Trac]

#10337: Easier embeds for 2.9  (oEmbed perhaps?)
----------------------------+-----------------------------------------------
 Reporter:  ryan            |       Owner:  Viper007Bond
     Type:  task (blessed)  |      Status:  assigned    
 Priority:  normal          |   Milestone:  2.9         
Component:  Shortcodes      |     Version:              
 Severity:  normal          |    Keywords:              
----------------------------+-----------------------------------------------
Changes (by Viper007Bond):

  * owner:  => Viper007Bond
  * status:  new => assigned


Comment:

 This was a widely requested feature in the 2.9 feature poll:

 http://wordpress.org/development/2009/07/2-9-vote-results/

 Since I've spent so much of my life [http://wordpress.org/extend/plugins
 /vipers-video-quicktags/ dealing with embeds], Jane asked me take a look
 at implementing easier embeds.

 I've been thinking about it over the past week or two and I'm currently of
 the opinion that implementing an [http://oembed.com/ oEmbed] client with
 some manually coded fallbacks for popular sites that don't support oEmbed
 yet would be the way to go.

 '''My Current Brainstorm'''

 New UI element is added, perhaps a new media button called like External
 Embed or something. I dunno, UI's aren't my strong suit.

 The user is prompted for the URL to the object (video, image, etc.).

 !WordPress then...

 1. Connects to the URL looking in the head for a discovery `<link>` to
 their oEmbed provider.[[BR]]
 2. If not found, it checks the URL against an internal (filterable) list
 of oEmbed providers. This is meant for sites that support oEmbed but that
 don't have discovery links.[[BR]]
 3. If still not found, then it checks the URL against and internal sudo-
 oEmbed provider. Similar http://oohembed.com/ but it'd be internal rather
 than relying on a third party service. This is meant for popular sites
 that we want to support but that don't support oEmbed themselves (for
 example YouTube).

 mdawaffe and I have been discussing this and the only real concern seems
 to be malicious HTML getting in from the provider (say hidden tracking
 codes, advertising, etc.) However this would still happen if the user was
 to just copy/paste in the code themselves.

 There's also the decision about whether to do this with shortcodes or not.

 '''The before method''' consists of the oEmbed result HTML being inserted
 directly into the post contents. The user can then see the HTML and
 remove/edit anything they want, if they desire. The drawback is if the
 provider updates their embed code, it's not updated on the blog. Although
 this can be a pro if the update consists of malicious HTML. The other
 problem is it's harder to change things like width/height as it's often
 defined multiple times.

 '''The after (shortcode) method''' consists of a shortcode being inserted
 into the post rather than the HTML. The oEmbed request is made on post
 display (and probably cached for performance purposes). This is future
 proof and probably easier on the user, but the user has no control over
 the HTML. This does allow `unfiltered_html` lacking users (i.e. WPMU) to
 embed though, which is both a pro and con.

 '''Lack Of Customization'''

 Another problem with oEmbed is the lack of customization. For example, you
 couldn't easily set a default color for Vimeo embeds.

 '''TL;DR'''

 I am thinking about using oEmbed for making for easy embeds, but I am
 concerned about possible security issues, lack of customization, and so
 forth. As such, I am looking for feedback and ideas.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/10337#comment:7>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software