Add unique capability for oembed

[jason_the_adams]

Ran into a very specific use case today wherein I have a custom user role with a custom WYSIWYG editor on their profile. The user role has unique capabilities for a couple custom post types with unique capabilities. The user needs to be able to paste a YouTube URL in their profile editor, but I found that it doesn't work.

After some digging, I found that the oEmbed ajax function wp_ajax_parse_embed() checks for current_user_can('edit_posts'). Also, the oEmbed REST API does the same thing in the WP_oEmbed_Controller::wp_ajax_parse_embed() method.

This is a problem for custom post types with custom capabilities. We don't want the user to have the edit_posts permission, but they do have the edit_custom_posts equivalent. While this isn't a problem for current_user_can('edit_post', $post_id) calls, as it uses the post to grab the post object and thereby post object capabilities, the edit_posts primitive check has no context.

Since we can't rely on being able to gather post object context (as, in my case, there may be no post object as we're on the user profile), I propose creating a single (or group) of oEmbed capabilities. Something like create_oembeds.

Wanted to gather some feedback and thoughts from the community before putting together a patch. Let me know what you think! :)

[joyously]

Is this ticket reporting a problem with the capability check for embeds or is it proposing a new capability? Or maybe both.

It seems to me that the existing capability check assumes a post context, which your use case has a problem with. Would putting a filter on that capability check work? Are there other places where embeds might be wanted, but checking edit_posts wouldn't work? Like comments or custom widgets?

Is it just embeds that has this problem? I've seen some other discussions about other places where core checks for a capability that doesn't work in all contexts. (I also have a use case for custom role with custom post type created with a custom editor, and I don't want the user to edit_posts. This seems likely to be common for sites with user-created content.)

[jason_the_adams]

Hi!

Replying to joyously:

Is this ticket reporting a problem with the capability check for embeds or is it proposing a new capability? Or maybe both.

Both. There is an issue with oembed capability checks as they require either a post context or the user to have edit_posts which doesn't fit custom post types with capabilities.

It seems to me that the existing capability check assumes a post context, which your use case has a problem with. Would putting a filter on that capability check work? Are there other places where embeds might be wanted, but checking edit_posts wouldn't work? Like comments or custom widgets?

Regarding the filter, that could work but the issue is that there isn't really any further context that a hook could do anything with. If there's a post, it's working fine; if there's no post, there's not much context.

You're right on with the other scenarios. That's why, along with my last point, I'm suggesting a new capability, similar to upload_files or other one-off capabilities. I think it's good to check if a user has a capability, I just don't think edit_posts is the right one as it impacts far too much else.

Is it just embeds that has this problem? I've seen some other discussions about other places where core checks for a capability that doesn't work in all contexts. (I also have a use case for custom role with custom post type created with a custom editor, and I don't want the user to edit_posts. This seems likely to be common for sites with user-created content.)

I'm trying to keep the scope of this issue to just embeds. I think other scenarios are worth considering, but I don't think there's a fundamental issue with the capability system, just niche situations that could use some tweaking.

---

Thanks for chiming in! I hope this helps clarify my thinking. :)