Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#46723 closed defect (bug) (fixed)

Feature Image disappears only in Gutenberg with CPT.

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


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.

There is an example plugin to reproduce the problem.


Attachments (3)

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

Download all attachments as: .zip

Change History (20)

5 years ago

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

#1 @miyauchi
5 years ago

  • Keywords has-patch added

#2 @miyauchi
5 years ago

I found similar problem to upload featured image.

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
5 years 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.

#4 @miyauchi
5 years ago

Related: #44581

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

5 years ago

#6 @Jtree5757
5 years 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
5 years 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
5 years 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.

4 years ago

#10 @sjnbham
4 years 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.


Last edited 4 years ago by sjnbham (previous) (diff)

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

4 years ago

#12 @TimothyBlynJacobs
4 years 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
4 years ago

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

Uploaded a refreshed patch with tests.

#14 @TimothyBlynJacobs
4 years 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
4 years ago


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
4 years 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
4 years 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.