[buddypress-trac] [BuddyPress] #2707: Support oembed

buddypress-trac at lists.automattic.com buddypress-trac at lists.automattic.com
Sat Jul 9 18:11:38 UTC 2011

#2707: Support oembed
  Reporter:  DJPaul  |      Owner:
      Type:  defect  |     Status:  new
  Priority:  major   |  Milestone:  1.3
 Component:  Core    |    Version:  1.3
Resolution:          |   Keywords:  has-patch needs-refresh dev-feedback

Comment (by boonebgorges):

 DJPaul said:
 > if WP core uses author_can() here, we should too.

 If I'm reading the discussion and the code correctly, this won't work.
 $attr[discover] will always return false, except for admins. At the very
 least, we can ask for the proposed WP patch to include a filter on this
 value. We'll want to include clear documentation on how oEmbed can be
 turned off, if admins decide that it is a security risk.

 > "embed_oembed_html" handles the output of the embedded content; I'd like
 to use a new one to avoid any possible conflicts with existing WP Embed
 plugins that deal with posts.

 On the other hand, it might be frustrating if someone is applying a filter
 to embeds in blog posts, only to find out that the same filters aren't
 being applied here. In either case, it's easy to fix - just add_ or
 remove_ filters - but we should probably make the decision based on the
 expected behavior. As I think about it, it'll be a bit easier to make it a
 different filter name, as it's pretty easy to add_filter(), while
 remove_filter() will require some logic to test whether the filtered
 content is on a BP page. So I guess I agree with r-a-y on balance.

 DJPaul, can you jump in with some thoughts before r-a-y goes to the
 trouble of refreshing the patch (which does not, as he notes, apply to the
 current trunk)?

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/2707#comment:22>
BuddyPress <http://buddypress.org/>

More information about the buddypress-trac mailing list