Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Author's Username is missing from Author dropdown. #17364

Open
TwisterMc opened this issue Sep 6, 2019 · 8 comments
Open

Author's Username is missing from Author dropdown. #17364

TwisterMc opened this issue Sep 6, 2019 · 8 comments
Labels
[Feature] Document Settings Document settings experience Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Design Feedback Needs general design feedback. REST API Interaction Related to REST API [Type] Enhancement A suggestion for improvement.

Comments

@TwisterMc
Copy link

Describe the bug
In the classic editor, the author drop down included their name followed by their username in parentheses. This is needed when there are two or more people with the same name, or one user that has different kinds of access for testing things. Gutenberg however only shows the author's name.

To reproduce
Steps to reproduce the behavior:

  1. Create a new post using the Classic editor.
  2. Click on the author drop down and you'll see users in this format: Name (username)
  3. Create a new post using the Gutenberg editor.
  4. Click on the author drop down and you'll see users in this format: Name

Expected behavior
I'd see users in this format: Name (username)

Screenshots
Gutenberg
Classic Editor
Quick Edit Post

Desktop (please complete the following information):

  • OS: MacOS 10.14.6 (18G95)
  • Browser Safari / Firefox / Chrome
  • Basically everything as it's a WordPress concern.

Additional context
I marked this as a bug because the author drop down is consistent across the backend, except for in Gutenberg. If you were to quick edit a post or page, the format would match what I'm expecting. Gutenberg seems to be breaking the consistency.

Additionally my client has nearly 150 users so what we have today in Gutenberg doesn't scale well if we just assume there will never be two users with the same name.

I've also dug for hooks or filters to try and customize what appears in the author drop down but have had no luck.

@swissspidy swissspidy added the [Feature] Document Settings Document settings experience label Sep 16, 2019
@draganescu draganescu added the [Type] Bug An existing feature does not function as intended label Apr 23, 2020
@draganescu
Copy link
Contributor

The REST API response to /wp/v2/users/&who=authors&per_page=100&_locale=user does not return username so that should be augmented 1st.

cc @spacedmonkey do you have any ideas here other than just adding a new field in the response with the username? I ask because slug already "seems" to be the username.

@mtias mtias added [Type] Enhancement A suggestion for improvement. and removed [Type] Bug An existing feature does not function as intended labels Aug 30, 2020
@skorasaurus skorasaurus added the REST API Interaction Related to REST API label Dec 17, 2020
@noisysocks
Copy link
Member

There's a new design by @javierarce for the Author dropdown in #41430 (comment). Perhaps we could include username in the line underneath the display name alongside the user's role?

It's worth noting is that users are able to select how they want their name to appear in profile settings. This should be respected.

Screen Shot 2022-07-15 at 13 14 23

@noisysocks noisysocks added the Needs Design Feedback Needs general design feedback. label Jul 15, 2022
@yanksyoon
Copy link

Hello! I am having the same issue with truncated response from the API - would there be a way to search by username only rather than including user's email in the search as well?
Thank you!

@draganescu
Copy link
Contributor

My previous comment is actually wrong. It appears that the endpoint is ready to return username, if it's present in the _fields param and the context is edit.

Currently the post authhor component in editor:

  • does not request username
  • sets the context to view

The context on request has to be view so that the list of authors can be retrieved even if the logged in user does not have edit context caps.

@swissspidy @TimothyBJacobs could you shed some light why on the user schema username is restricted to the edit context? It seems from the OP that the data is visible in author lists in other WP editors. Would you advise this control callse with an edit context just to get the username or change the schema to allow username (which is a user detail) be available in the view context.

I remember seeing people wanting to hide usernames for security reasons so I will assume the solution here is to:

  • add the username to the fields requested by the control
  • change the context to be edit, not sure what the harm here would be

@TimothyBJacobs
Copy link
Member

Yeah, the username is not intended to be a public field so it's only available in edit. There is no cap like view_usernames, so we have to be more blunt. Fundamentally, we can't be as loosey goosey as a PHP interface (so to speak), because we aren't building bespoke endpoints for each interface.

So I'm not sure what the right solve here is, or if there even is a solve.

We could have a larger conversation around introducing a context like block-editor. That would be available to any user who can use a block editor. And then potentially expose the username field in the block-editor context. But even that isn't so obvious, for instance what happens with the "Block Editor Everywhere" project. It'd probably be unexpected that all form users on w.org could see usernames.

@draganescu
Copy link
Contributor

Maybe then only users who can request the edit context will see the username like the OP exemplifies. Like in the editor if the logged in user is admin we request with edit and if not we request with view and no username appears in the control 🤷🏻

@TimothyBJacobs
Copy link
Member

Yeah I think that would be where I lean to for a practical solve. The client can know whether the user has edit permissions, and can alter it's request appropriately.

@draganescu draganescu added the Good First Issue An issue that's suitable for someone looking to contribute for the first time label May 1, 2024
@abhi3315
Copy link
Contributor

I was thinking about whether there should be an autocomplete feature to select authors. It could be very useful, especially if there are a lot of authors on a site. Although there are many plugins available to handle this, such as Co-Author Plus, having an autocomplete feature to list authors would make sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Document Settings Document settings experience Good First Issue An issue that's suitable for someone looking to contribute for the first time Needs Design Feedback Needs general design feedback. REST API Interaction Related to REST API [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

10 participants