Bug: Author role can't add a featured image uploaded by someone else

[christincooper]

In the block editor screen, on the right-side where we have the featured image panel, if a user is an author and can 'upload_files', the featured image that is not their own image will not load up when selected. This bug is only present when user selects an image uploaded by someone else.

Reproduce:

1. As an author user, on the post editing screen, click the Set Featured Image button.
2. Select an image that is NOT uploaded by this user. So an image uploaded by a different user.
3. Now, you will see a never-ending loading icon:

Works fine with images uploaded by the user themselves.

Tested on WP 5.3 and several environments.

Probable cause of this bug:

The Block Editor uses RESTful API to facilitate its functionality and the endpoint that is responsible for media attachments, for some unthoughtful reasons, checks if the current author is allowed to update the image that is about to be used as Features Image.

Maybe this part is the gremlin:

if ( $post && ! $this->check_update_permission( $post ) ) {
    return new WP_Error( 'rest_cannot_edit', __( 'Sorry, you are not allowed to edit this post.' ), array( 'status' => rest_authorization_required_code() ) );
}

Not sure.

An obvious fix would be to add edit_others_posts to author roles, but that defeats the main idea of the author role.

This is clearly a severe bug. Please let me know if you have questions to reproduce this bug.

[gziolo]

I can confirm that this bug exists in the last version of the Gutenberg plugin (6.9).

[garretthyder]

Related Core Trac Ticket - https://core.trac.wordpress.org/ticket/47291

[tomjn]

Is the bug about setting the featured image in the data? Or is it about rendering the featured image once it's set?

The code responsible for fetching the image for rendering is here:

gutenberg/packages/block-library/src/post-featured-image/edit.js

Line 16 in 32aaed9

featuredImage && select( 'core' ).getMedia( featuredImage ),

[tomjn]

Having dug a little deeper, getMedia is an alias for getEntity, and it's used in other places. I wouldn't be surprised if this manifested in previews of the latest posts block.

So I would suggest writing a test that compares fetching an attachment of another author in the edit context, and the non-edit context, from a user with the author role. If the test passes then the issue is likely with Gutenberg. If it fails, then the issue is probably in WP Core in the REST API.

[gchtr]

For me, this does not only happen with the featured image, but for any image that is requested through the media endpoint in the REST API by an author, if the image was uploaded by another user.

For now, I worked around this by allowing all users with a role of upload_files to edit other attachment posts. This is a little more fine-grained than adding edit_others_posts to author roles, but not ideal either.

add_filter( 'register_post_type_args', function( $args, $post_type ) {
	if ( 'attachment' !== $post_type ) {
		return $args;
	}

	$args['capabilities']['edit_others_posts'] = 'upload_files';

	return $args;
}, 10, 2 );

[christincooper]

@gchtr Thanks for this. The approach is useful for smaller platforms, but not for sites with many users, as it essentially gives them the capability to edit any image!

@gziolo Are there any plans on fixing this bug? It is severe given that it is currently affecting all multi-author sites. What better reason do we need to prioritize this? =)

[gziolo]

@anthonyburchell or @getsource – is this bug on your radar? I don't have enough expertise to judge myself how important this fix would be. I only know that I was able to reproduce it a few months ago.

[christincooper]

@anthonyburchell and @getsource - did you have a chance to look into this? Thank you.

[christincooper]

@anthonyburchell or @getsource or @gziolo
Is there any way you can look into resolving this bug? It's been a year since this was submitted. Note that currently, it affects all multi-author sites to a level where it is not possible to attach a featured image properly.

[kiwifraise]

I do have the same problem on my site.
I am using custom role and has assigned edit_others_posts capability...
Featured image wont load if image has been upload by someone else.
$role = add_role('myrole', 'My Role',get_role('author')->capabilities);
When I set my role from editor capabilities, featured image is showing.

[skorasaurus]

#22847 also discusses this.

[vyskoczilova]

The bug is still present. I have a custom user role with upload_files capabilities, I can see all files, but when I try to select them, I can't use them and it silently still try to load the file but the console is full of the same error as mentioned above.

Is there any workaround?

[meloniq]

@vyskoczilova please try this one:

	/**
	 * Change context for media REST requests to fix issue with selecting images in Featured Image metabox.
	 *
	 * @see https://core.trac.wordpress.org/ticket/47291
	 *
	 * @param mixed           $result  Response to replace the requested version with. Can be anything
	 *                                 a normal endpoint can return, or null to not hijack the request.
	 * @param WP_REST_Server  $server  Server instance.
	 * @param WP_REST_Request $request Request used to generate the response.
	 *
	 * @return mixed
	 */
	function xyz_rest_change_media_context( $result, $server, $request ) {
		// apply only to GET method
		$method = $request->get_method();
		if ( 'GET' !== $method ) {
			return $result;
		}

		$url = $request->get_route();
		if ( ! is_user_logged_in() || ( false === strpos( $url, '/wp/v2/media/' ) ) ) {
			return $result;
		}

		if ( 'edit' === $request->get_param( 'context' ) ) {
			$request->set_param( 'context', 'view' );
		}

		return $result;
	}

add_filter( 'rest_pre_dispatch', 'xyz_rest_change_media_context', 10, 3 );

[vyskoczilova]

@meloniq Thanks a lot! It works but it brings a new issue:

1. When I go to the media library for the first time, I can see ALL media files and select one.
2. When I remove the selected file and try to get back to the media library, I see "Nothing in the media library" for a long while but after few seconds it gets replaced with correct files (but no sign of loading from user experience side).
3. When I upload my very own file and try to replicate that I can see my file first and then the others get loaded.

And I've spotted a kind of related capability issue with REST API:

1. User has just capabilities to completely edit my CPT and read & upload files: edit_CPT, edit_CPTs, edit_others_CPTs, publish_CPTs, read_CPT, read_private_CPTs, delete_CPT, delete_CPTs, delete_private_CPTs, delete_others_CPTs, edit_published_CPTs, edit_private_CPTs, delete_published_CPTs, read, upload_files
2. When I open the post, it tries to load taxonomies (not used for my CPT) and user REST API too. And obviously it fails somewhere.

I've created a screencast here: https://www.loom.com/share/93247e66ba72474ca0db78612f9f565f where you can see both issues.

[rfischmann]

Wow, this seems like a severe bug to me to stay uncorrected for a year and a half. It's such a basic feature and a common action (for authors to use already-uploaded images as a featured one) that I wonder why so few people manifested here.

[christincooper]

Wow, this seems like a severe bug to me to stay uncorrected for a year and a half. It's such a basic feature and a common action (for authors to use already-uploaded images as a featured one) that I wonder why so few people manifested here.

It's bigger than that unfortunately. All images that are not uploaded by the author themselves will fail. For example, using an author account, try inserting an image you did not upload yourself. And then click on it. You will see that some block settings are missing, like image sizes. This is because it is failing to fetch the image.

I have been trying to push this to the higher ups at WordPress and no one seems to understand or care for it.

Please help spread the word.

[tomjn]

I believe this is not a block editor issue but a REST API issue, and that the trac ticket was incorrectly closed by @garretthyder due to the misunderstanding of the nature of the bug.

I would also note that issues like this stay like this unless somebody champions them. Long standing tickets that haven't been fixed in a long time stay unfixed unless you bring them to attention. SImply bumping them with a comment is the most inefficient method of doing this as it only pokes those people who are subscribed to the issue, it'll get lost in the noise. Raise it in the weekly meeting agendas instead.

Also a test case demonstrating it is, or is not a REST API bug

[Mamaduka]

Created PR that should fix this issue #33567.

[reneroboter]

I've still this kind of error. I've added the upload_files capability to the contributor role. When I use the default WordPress image block everything work as expected. However when I use our custom WordPress block which use the WordPress MediaUpload from wp.editor then I got a 403 from the following REST API.

GET /wp-json/wp/v2/media/<MEDIA_ID>?context=edit&_locale=user

Is my bug related to this one?

[Mamaduka]

@reneroboter, to avoid 403 errors for users with low permissions, the GET request to fetch media should use context=view. See #33567.