Feature Image disappears only in Gutenberg with CPT.

[miyauchi]

Gutenberg is using the following API and it needs edit_posts capability to access it.
But if we apply the custom role for the post-type, it will have a capability like edit_events or so.
So we can't see feature image metabox for the post type with the gutenberg.

​https://github.com/WordPress/WordPress/blob/c41dede996bbb50055f914d9094be59f659a4d14/wp-includes/rest-api/endpoints/class-wp-rest-themes-controller.php#L60-L66

There is an example plugin to reproduce the problem.
​https://github.com/miya0001/reproduce-12198

Related: ​https://github.com/WordPress/gutenberg/issues/12198

[miyauchi]

It allows to access /themes endpoints if the user has upload_files capability.

[miyauchi]

I found similar problem to upload featured image.
​https://github.com/WordPress/WordPress/blob/master/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php#L1384

User needs capability edit_post to attach featured image for the Gutenberg.
But user doesn't have edit_post if the custom post type is using custom role.

[miyauchi]

I tried to check the user has $post_type->cap->edit_post capability for the parent post type of the attachment.
But I run into the problem that the attachment possibly has another parent post type like page.

I tried to add following lines in check_update_permission() and it looks good.

if ( 'attachment' === $post->post_type ) {
        return current_user_can( 'upload_files' );
}

But I am concerned about introducing security risk.

[miyauchi]

Related: #44581

[Jtree5757]

If anyone else runs into this issue, temporary workaround is to revert to the old editor.

Just ran into this on a client site.Luckily they were just managing basic paragraph text for the custom post type that had the issue.

[jrchamp]

There is no workaround for this if you have already developed an entire plugin for the Block Editor. Lost 3 days to this bug while I fought with map_meta_cap and user_has_cap trying to figure out what I must have done wrong. Thank you @miyauchi for suggesting reasonable workarounds. For now, I'm doing something much more evil because I can't ship a modified version of WordPress core.

@desrosj & @kadamwhite: edit_posts was a nice idea, but it is definitely not sufficient. Please help!

[kadamwhite]

Provisionally milestoning for the next release

[sjnbham]

I ran into this issue when trying to set up a user to only have access to create, edit, publish, and delete events using the popular The Events Calendar plugin by Modern Tribe. To reproduce, you have to enable the block editor option in the event plugin and then assign the following permissions below. Without adding edit_posts the feature image metabox isn't presented.

create_tribe_events
create_tribe_organizers
delete_others_tribe_events
delete_others_tribe_organizers
delete_others_tribe_venues
delete_private_tribe_events
delete_private_tribe_organizers
delete_private_tribe_venues
delete_published_tribe_events
delete_published_tribe_organizers
delete_published_tribe_venues
delete_tribe_events
delete_tribe_organizers
delete_tribe_venues
edit_others_tribe_events
edit_others_tribe_organizers
edit_others_tribe_venues
edit_private_tribe_events
edit_private_tribe_organizers
edit_private_tribe_venues
edit_published_tribe_events
edit_published_tribe_organizers
edit_published_tribe_venues
edit_tribe_events
edit_tribe_organizers
edit_tribe_venues
level_0
publish_tribe_events
publish_tribe_organizers
publish_tribe_venues
read
read_private_tribe_events
read_private_tribe_organizers
read_private_tribe_venues
upload_files

[TimothyBlynJacobs]

This change looks sensible to me as a stop gap measure before considering loosening the restrictions even more. I'd like to see test coverage on this change.

We can also drop the is_user_logged_in check while we're at it.

[TimothyBlynJacobs]

Uploaded a refreshed patch with tests.

[TimothyBlynJacobs]

Thinking about this further, I don't think the issue is that users who can upload_files can't see information about the theme, but rather any user who can edit a particular post type can't see the theme. In other words, this is an issue for any theme support that the block editor references.

As such, I've uploaded a new patch that checks if the user has access to call the edit_posts cap of any of the show_in_rest post types.

@miyauchi could you confirm this patch still solves your problem?

[miyauchi]

@TimothyBlynJacobs

Thanks, it looks good to me.

However I am worried about that if user has a permission of edit_* for one of CPTs, this solution always return true. right?

But I don't have better idea.
I wish if /themes can detect current post type haha :)

[TimothyBlynJacobs]

Great, thanks for confirming @miyauchi!

However I am worried about that if user has a permission of edit_* for one of CPTs, this solution always return true. right?

Yep, that's intentional. The idea is that if the user can edit any CPT that would use the block editor, they'll need to be able to see the /themes endpoint.

We'll need to overhaul the permissions model for this resource at some point, but given that this data is essentially public ( it lives in stylesheets, or is explicitly for front-end rendering ), I'm comfortable with the current permission checks.

[kadamwhite]

In 47361:

REST API: Permit access to the themes controller if user can edit any post type.

Check a more exhaustive list of post type editing caps beyond "edit_post" to ensure custom user roles with access to to specific post types may still use block editor functionality depending on theme features.

Props miyauchi, TimothyBlynJacobs.
Fixes #46723.