WordPress.org

Make WordPress Core

Opened 18 months ago

Closed 7 months ago

#46723 closed defect (bug) (fixed)

Feature Image disappears only in Gutenberg with CPT.

Reported by: miyauchi Owned by: kadamwhite
Milestone: 5.4 Priority: normal
Severity: normal Version: 5.1
Component: REST API Keywords: has-patch has-unit-tests commit
Focuses: Cc:

Description

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

Attachments (3)

46723.patch (942 bytes) - added by miyauchi 18 months ago.
It allows to access /themes endpoints if the user has upload_files capability.
46723.diff (2.2 KB) - added by TimothyBlynJacobs 7 months ago.
46723.2.diff (2.6 KB) - added by TimothyBlynJacobs 7 months ago.

Download all attachments as: .zip

Change History (20)

@miyauchi
18 months ago

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

#1 @miyauchi
18 months ago

  • Keywords has-patch added

#2 @miyauchi
18 months ago

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.

#3 @miyauchi
18 months ago

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.

This ticket was mentioned in Slack in #core-restapi by miyauchi. View the logs.


18 months ago

#6 @Jtree5757
13 months ago

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.

#7 @jrchamp
11 months ago

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!

#8 @kadamwhite
11 months ago

  • Milestone changed from Awaiting Review to 5.4

Provisionally milestoning for the next release

This ticket was mentioned in Slack in #core-restapi by timothybjacobs. View the logs.


9 months ago

#10 @sjnbham
9 months ago

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

Last edited 9 months ago by sjnbham (previous) (diff)

This ticket was mentioned in Slack in #core-restapi by timothybjacobs. View the logs.


8 months ago

#12 @TimothyBlynJacobs
8 months ago

  • Keywords needs-refresh needs-unit-tests added; has-patch removed

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.

#13 @TimothyBlynJacobs
7 months ago

  • Keywords has-patch has-unit-tests added; needs-refresh needs-unit-tests removed

Uploaded a refreshed patch with tests.

#14 @TimothyBlynJacobs
7 months ago

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?

#15 @miyauchi
7 months ago

@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 :)

#16 @TimothyBlynJacobs
7 months ago

  • Keywords commit added

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.

#17 @kadamwhite
7 months ago

  • Owner set to kadamwhite
  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.