Author Dropdown menu missing in Quick Edit

[iheartdogs]

My publishing team just reached out to me regarding a useful feature. This feature allowed my writing team to change the author for a post through "Quick Edit" under each post. This feature is now visibly gone from the Quick Edit menu, forcing writers to open each post in a separate tab and change the author from there. Can you provide instructions on how to re-enable the change author field in Quick Edit?

Best,
Duke

[sabernhardt]

I found the Author dropdown in my installation, both as an admin user and as an editor. Could #28230 be related?

[TimothyBlynJacobs]

Does your site have more than 10k users @iheartdogs? If so, as of WP 6.0 your site would be flagged as having a large user count. When this happens, the Quick Edit author dropdown is not rendered to avoid expensive database queries.

You can turn off this functionality with the following code snippet.

add_filter( 'wp_is_large_user_count', '__return_false' );

You can read more about this change in it's ​dev note.

[webcommsat]

Thank you @iheartdogs for your question. Thanks too to @sabernhardt and @TimothyBlynJacobs for your comments. On testing this in the component tickets review this week, I could also find the Author dropdown in my installation, when logged is as an admin user and as an editor user. If sites have more than 10K users, the Quick Editor author dropdown is not rendered from version 6.0. This appears to answer the questions raised. Can I suggest we therefore close this ticket as there has not been any further issues reported? Thank you.

[TimothyBlynJacobs]

Yep, good call @webcommsat!

[lenasterg]

Hi.
I want to reopen this ticket.
Using the function wp_is_large_user_count() in the posts Quick edit feature of a subsite in a multisite installation is not appropriate for determining whether the 'Change Author' option should be hidden. This is because the function wp_is_large_user_count() checks for the total number of users in the entire network, rather than the number of users who can add or edit posts in the current subsite.

For instance, a network may have over 10,000 users, but a particular subsite may only have 2 or 3 users who have the ability to write posts. Therefore, relying on the function wp_is_large_user_count() to decide whether or not to hide the 'Change Author' option leads to incorrect outcomes.

[oglekler]

I tested this and wp_is_large_user_count() is getting the amount of users for entire network (global $current_site) instead of the current site (global $current_blog). This is probably intentional, because we cannot select users for the current site from wp_users and would need to add join from wp_usermeta with not empty user_level or capabilities for the current site (blog).

[lenasterg]

Replying to oglekler:

I tested this and wp_is_large_user_count() is getting the amount of users for entire network (global $current_site) instead of the current site (global $current_blog). This is probably intentional, because we cannot select users for the current site from wp_users and would need to add join from wp_usermeta with not empty user_level or capabilities for the current site (blog).

This check should not be applied when performing a bulk edit of posts on a sub-blog, as it is also not applied during individual post edits or when displaying members of a sub-blog on the members page, where the users of the sub-blog are shown without any issue.
For consistency and proper functionality, I kindly request that this check be removed from the specified part of the code: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-posts-list-table.php#L1727.

The solution suggested from @TimothyBlynJacobs - to use the

add_filter( 'wp_is_large_user_count', '__return_false' );

isn't not the best one cause it removes the check from the entire multisite installation - which is useful in other places.

[realloc]

You could consider adjusting this logic to evaluate the user count per site instead of per network. The following code illustrates this idea:

add_filter( 'wp_is_large_user_count', function( $is_large_user_count ) {
	if ( ! is_multisite() ) {
		return $is_large_user_count;
	}

	$user_count = count_users( 'time', get_current_blog_id() );

	return $user_count['total_users'] > 10000;
} );

This approach preserves the intent of the performance optimization while ensuring that subsites with a few users retain normal Quick Edit functionality.

What do you think?

[johnjamesjacoby]

This is a 2-part problem:

1. Querying the database for users becomes an expensive operation as the number of registered users grows
2. A single select with potentially 10k options is a bad user experience, and may even slow down the browser

Keep in mind this code is not multisite-specific.

wp_is_large_user_count() is the correct function to use because of the way that User Role & Capability data is stored in the database, the same database performance concern exists for both single & multi-site installations.

For instance, a network may have over 10,000 users, but a particular subsite may only have 2 or 3 users who have the ability to write posts. Therefore, relying on the function wp_is_large_user_count() to decide whether or not to hide the 'Change Author' option leads to incorrect outcomes.

Not exactly, but I do understand what you mean.

The way it works, is if there are more than 10k users in the wp_users database table, there will be more than 100k rows in wp_usermeta which is where roles & caps are stored. The database query to only get users with the $post_type_object->cap->edit_posts capability will require joining both of those tables together, and is highly likely to be slow enough to be noticeable, even if only 2 or 3 users can actually author posts.

Re-closing this ticket as worksforme, because it is actually working as intended, and a working solution to bypass it exists in the comments.

If we do want to improve this UX, I think a new ticket with an enhancement proposal might be the way to go? For example, making this a search & autocomplete (like Tags uses) might be a decent compromise; show an input instead of a select, etc...?

[westonruter]

Replying to johnjamesjacoby:

If we do want to improve this UX, I think a new ticket with an enhancement proposal might be the way to go? For example, making this a search & autocomplete (like Tags uses) might be a decent compromise; show an input instead of a select, etc...?

I believe that would be #19867 (ahem, it's 14 years old).