[wp-trac] [WordPress Trac] #10337: Easier embeds for 2.9 (oEmbed perhaps?)

[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:              
----------------------------+-----------------------------------------------

Comment(by lloydbudd):

 Replying to [comment:7 Viper007Bond]:
 >
 > This was a widely requested feature in the 2.9 feature poll:
 >
 > http://wordpress.org/development/2009/07/2-9-vote-results/

 I'm excited by this work!

 I do think an important context of the voting results is that
 WordPress.com customers (a restricted WordPress MU environment with
 limited embed options) were called to vote:
 http://en.blog.wordpress.com/2009/07/08/media-feature-vote/

 > 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.

 Strengthen the muscle by working it ;-)

 There is a UI for this in WordPress already, but I don't think it works as
 many would expect.

 All of the Upload/Insert include From URL, so for Video I go there and
 enter a YouTube URL thinking it will add that video to the post, but
 instead it currently (v2.8.x and trunk r11731) just creates a link to the
 URL with the text you enter as the title.


 > 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.

 Correct, though expectations sometimes change when there is a different
 experience.


 > 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.

 I think you nail the issue of the experience not being that much better
 than pasting in the embed code oneself.

 > '''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.

 How it fits into the existing roles and permissions system needs to be
 vetted.

 Also important will be clear, immediate feedback for a web service that is
 not supported and generic instructions for copy & pasting embed code
 provided.

 I think oEmbed is a great default experience, but if technically feasible
 would be great to have these short codes of a little different style, with
 traditional short code taking precedence if already loaded (would have to
 extend their definitions).

 For example, user pastes link to Flickr video:

 1. Check if traditional short code in system matching that definition. Can
 provide explicit fields for the possible parameters defined for the short
 code (addresses MU, security, and customization/flexibility).

 2. If unfiltered HTML cap. then use oembed stages you describe above.

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