Post author dropdown missing users when number of users exceeds 100

[ghost]

Issue Overview

Author dropdown does not show all users.

Steps to Reproduce (for bugs)

1. WordPress 4.9.2, Gutenberg 2.0.0
2. 120 users
3. Edit post
4. Open author dropdown

Expected Behavior

List of 120 users

Current Behavior Gutenberg

List of 100 users

Current Behavior Classic Editor

List of 120 users

Possible Solution

Use X-WP-TotalPages and/or X-WP-Total headers in REST API response to get missing users.

[danielbachhuber]

@TKES A couple follow-up questions to clarify:

1. Just to confirm, does the WordPress user have access to list all 120 users?
2. How did you verify only 100 users were present? Did you scroll through the entire list?

Thanks!

[ghost]

1. User has administrator role.
2. By looking at list, scrolling through list, looking at releated REST API request.

[danielbachhuber]

Thanks @TKES — appreciated.

[spencerfinnell]

There is a hard limit here: https://github.com/WordPress/gutenberg/blob/master/editor/components/post-author/index.js#L88

[danielbachhuber]

@spencerfinnell Correct. wp/v2/users has a per_page cap of 100 items. We'd either need to:

1. Traverse all pages to load all potential items.
2. Show "common" users by default and permit some search auto-complete to get to the unlisted users.

[ghost]

@danielbachhuber The only acceptable solution is 1.

Similar code will be required anyway to fix #4632, #4623 and more issues like missing tag entries, missing custom taxonomy entries, etc.

And the hardcoded ? in REST API call needs to be fixed as well, it won't work with plain permalinks, as explained here by @bobbingwide

[danielbachhuber]

Another idea would be to load the initial set of users when Gutenberg loads, and then progressively load all remaining users when the UI element is focused.

[ghost]

@danielbachhuber "Another idea" would fail. If real author is not in initial set of users, saving the post without focusing UI element would still unintentionally change its author.

[adamsilverstein]

What about adding a (debounced) search feature here so you could start typing the username and drill down to the correct user?

[bobbingwide]

Some other things to note:

• The response can contain many users who couldn't possibly be the Author of the post. e.g. Subscribers.
• IMO the original request should include a filter to eliminate unwanted results.
• Also, there's a lot of data that's not going to be used.
• The final post author select list only uses the ID and display_name fields.

[StuartFeldt]

So is the need here to add some sort of pagination/traverse options to withAPIData?

[robbiet480]

As an alternative, could the query params include roles=editor,administrator,author,contributor? The only reason we hit the 100 user limit is because of push notification subscribers...

[jeffpaul]

This ticket was mentioned in Slack in #core-editor by jeffpaul. View the logs.

[lkraav]

2.4.0: I just attempted monkey-patching the query to test for .level_10 but for some reason still seeing everybody irrelevant.

[adamsilverstein]

Pushed a proposed fix that changes the selector into a searchable dropdown in #5921.

Worth noting the existing classic editor selector dropdown also has some scalability issues, especially when you get to thousands of users which isn't at all uncommon for WordPress sites. This trac ticket covers the discussion which includes mention of a search picker like the one included on the PR:

https://core.trac.wordpress.org/ticket/19867