Search for plugin authors should also consider their display name

[threadi]

When searching for a plugin author in the WordPress backend, you currently have to enter their author slug. Their display name used in the plugin directory is not found. This can be difficult for users who are not aware of the difference, as they may not be able to find plugins by a specific author.

Examples:

• Searching for "Matt Mullenweg" (as displayed on the Hello Dolly plugin page ​https://wordpress.org/plugins/hello-dolly/) returns no results. You have to search for "Matt" to get results.
• I first noticed this with "dreihochzwo", whose slug is "tmconnect". Searching for "dreihochzwo" returns no results; only searching for "tmconnect" returns all of his plugins.

One would expect the search to use either the display name alone or both together.

[sanket.parmar]

Thanks for the detailed report and the clear examples — this is a genuine UX pain point.

The root cause is in WP_Plugin_Install_List_Table::prepare_items() (source:src/wp-admin/includes/class-wp-plugin-install-list-table.php). When the search type is author, the term is passed directly as the author argument to plugins_api(), which forwards it to the WordPress.org API. The API's author parameter only matches by username/slug, not by display name.

One possible approach on the WordPress core side would be a fallback: if an author search returns zero results, automatically retry using the general search parameter with the same term. This would be a client-side workaround that requires no API changes.

However, before pursuing that direction, it would be worth confirming with the WordPress.org API team whether the search parameter on their /plugins/info/1.2/ endpoint already indexes author display names — if it does, the fallback would work well in practice. If not, the ideal fix would be on the API side to support display name matching in the author parameter directly, which would be a cleaner and more reliable solution.

A core-side patch would be straightforward either way, but it makes sense to clarify the API behaviour first to avoid introducing an extra HTTP request that may not solve the underlying issue.