[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/>
BuddyPress
More information about the buddypress-trac
mailing list