[wp-trac] [WordPress Trac] #56129: Author Dropdown menu missing in Quick Edit
WordPress Trac
noreply at wordpress.org
Mon Oct 6 20:17:29 UTC 2025
#56129: Author Dropdown menu missing in Quick Edit
-----------------------------+--------------------------
Reporter: iheartdogs | Owner: (none)
Type: defect (bug) | Status: closed
Priority: normal | Milestone:
Component: Quick/Bulk Edit | Version: 6.0
Severity: normal | Resolution: worksforme
Keywords: | Focuses: performance
-----------------------------+--------------------------
Changes (by johnjamesjacoby):
* keywords: reporter-feedback 2nd-opinion dev-feedback =>
* status: reopened => closed
* focuses: multisite, performance => performance
* resolution: => worksforme
Comment:
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...?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/56129#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list