Author in post panel show '(No author)' for editors in some cases

[karthikeya-io]

Description

Trac ticket: https://core.trac.wordpress.org/ticket/56429

This issue occurs because here the getUsers selector returns only the first 100 users. If there are more than 100 authors and the current post's author isn't included in the initial query result, that author isn't stored in the store.

gutenberg/packages/editor/src/components/post-author/hook.js

Lines 29 to 35 in 0c71098

	return {
	authorId: _authorId,
	authors: getUsers( query ),
	postAuthor: getUser( _authorId, BASE_QUERY ),
	isLoading: isResolving( 'getUsers', [ query ] ),
	};
	},

The code currently uses getUser to fetch the post's author, which results in a request to /wp/v2/users/:id. This request fails for Editors because they lack the list_users capability, returning a 403 error — but it works for Administrators.

Step-by-step reproduction instructions

Please see: https://core.trac.wordpress.org/ticket/56429#comment:4

Note: Before PR #67330, the per_page value was 50. It's now 100. So, to reproduce the issue, make sure you have more than 100 users.

Screenshots, screen recording, code snippet

Environment info

No response

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[Mamaduka]

I'm unable to reproduce the issue even if I generate a couple of hundred authors - wp user generate --role=editor --count=200.

Updated: I managed to reproduce the problem, which is really weird.

All those requests are made with context=view, which allows even users with low capability to fetch minimal data. I think the 403 error is caused by something else. The proposed fix (#69922) won't change anything.

You can try this by using the test URL in an incognito window.

https://local.test/wp-json/wp/v2/users/1?context=view&_fields=id%2Cname&_locale=user

[Mamaduka]

I tracked this down to the user's REST API controller. There's a logic difference between get_item_permissions_check and get_items_permissions_check.

• get_item_permissions_check - allows context=view requests as long as the user has one post published.
• get_items_permissions_check - allows context=view query for authors as long as the current user can edit posts.

I think this needs to be fixed on the REST API side. Otherwise, we will always be patching similar issues in editor components.

cc @TimothyBJacobs, @spacedmonkey

[karthikeya-io]

I think this needs to be fixed on the REST API side. Otherwise, we will always be patching similar issues in editor components.

Yes, I’ve noticed that other blocks like Author, Author Name, and Author Biography also log a 403 error for Editors. These blocks use context=edit, which we might need to update to context=view after updating the REST API.

Maybe we can update get_item_permissions_check to allow access if the user can edit the post and the context is not 'edit', similar to get_items_permissions_check.

diff --git src/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php src/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php
index 78e1b38b1b..0d0db3fb90 100644
--- src/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php
+++ src/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php
@@ -473,19 +473,29 @@ class WP_REST_Users_Controller extends WP_REST_Controller {
 			return $user;
 		}

-		$types = get_post_types( array( 'show_in_rest' => true ), 'names' );
+		$types       = get_post_types( array( 'show_in_rest' => true ), 'objects' );
+		$types_names = get_post_types( array( 'show_in_rest' => true ), 'names' );

 		if ( get_current_user_id() === $user->ID ) {
 			return true;
 		}

+		if ( 'edit' !== $request['context'] ) {
+			foreach ( $types as $type ) {
+				if ( post_type_supports( $type->name, 'author' )
+					&& current_user_can( $type->cap->edit_posts ) ) {
+					return true;
+				}
+			}
+		}
+
 		if ( 'edit' === $request['context'] && ! current_user_can( 'list_users' ) ) {
 			return new WP_Error(
 				'rest_user_cannot_view',
 				__( 'Sorry, you are not allowed to list users.' ),
 				array( 'status' => rest_authorization_required_code() )
 			);
-		} elseif ( ! count_user_posts( $user->ID, $types ) && ! current_user_can( 'edit_user', $user->ID ) && ! current_user_can( 'list_users' ) ) {
+		} elseif ( ! count_user_posts( $user->ID, $types_names ) && ! current_user_can( 'edit_user', $user->ID ) && ! current_user_can( 'list_users' ) ) {
 			return new WP_Error(
 				'rest_user_cannot_view',
 				__( 'Sorry, you are not allowed to list users.' ),

[Mamaduka]

Yes, we'll need to adjust the singular item permission checks in the REST API, but we should be cautious to avoid accidentally leaking user data.

I've requested feedback from REST API component maintainers. Let's wait for their suggestions.

Meanwhile, we can close #69922.

[TimothyBJacobs]

Interesting. We should definitely spin up a Core trac ticket.

I'm not entirely sure why the decision was made if it was an intentional difference. I'll ask around.

[Mamaduka]

Thank you, @TimothyBJacobs!

Should I modify the ticket where this issue was initially reported (https://core.trac.wordpress.org/ticket/56429) or create a new one?