WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#31251 closed enhancement (fixed)

Show username in wp_dropdown_users when deleting users, not display name

Reported by: krogsgard Owned by: boonebgorges
Milestone: 4.5 Priority: normal
Severity: normal Version: 4.1
Component: Users Keywords: has-patch
Focuses: administration Cc:
PR Number:

Description

wp_dropdown_users, by default, shows the display name for a user.

The function is used in users.php to show a list of users, so that you can attribute posts to someone when deleting an existing user. It should show the username so that the exact list shows up. I just had a situation trying to delete a user where I had multiple "Tom"s show up as display names, with no idea which to delete.

https://cldup.com/RSlM9jG45g.png

We can easily use the show parameter where wp_dropdown_users is used in users.php to delete a user to make this actually usable when deleting users.

Attachments (3)

31251.diff (720 bytes) - added by krogsgard 5 years ago.
use the show parameter in wp_dropdown_users when reassigning posts while deleting a user
31251.2.diff (1.8 KB) - added by krogsgard 5 years ago.
Change default 'show' to empty, and if nothing is specified, show both display_name and user_login
31251.patch (6.2 KB) - added by krogsgard 5 years ago.
Add unit tests, inline docs. Huge thanks to @boone for the walkthrough.

Download all attachments as: .zip

Change History (28)

@krogsgard
5 years ago

use the show parameter in wp_dropdown_users when reassigning posts while deleting a user

#1 @krogsgard
5 years ago

  • Keywords has-patch added

This ticket was mentioned in Slack in #core by krogsgard. View the logs.


5 years ago

#3 @helen
5 years ago

Every time I do my own user dropdown/autocomplete thing, I put display name plus username (typically the user_nicename) in parens, because the ambiguity and variation drives me nuts. I wonder if we should be doing this, and in more places.

Last edited 5 years ago by helen (previous) (diff)

#4 @krogsgard
5 years ago

@helen Can wp_dropdown_users take both params for show? I've never tested it. But dual would be ideal. Maybe this should be a patch on the defaults for wp_dropdown_users vs this instance of it :)

#5 @helen
5 years ago

Nope. Would be nice to look at a more general option, yeah :)

@krogsgard
5 years ago

Change default 'show' to empty, and if nothing is specified, show both display_name and user_login

#6 @krogsgard
5 years ago

Winging it a little bit, but from what I can tell, changing show to '' and then adding display_name to the fields to return in get_users doesn't have any repercussions in core. And then, if someone has specified what to show in their usage of wp_dropdown_users, it'll still operate that way. But if they don't, it'll show the display name with the username in parenthesis.

One small potential downside is if it's used on the front-end and they don't want the username to show... but that's pretty mild in my opinion. Usernames are easy to find and not worth obfuscating.

#7 @DrewAPicture
5 years ago

  • Milestone changed from Awaiting Review to 4.2

@krogsgard
5 years ago

Add unit tests, inline docs. Huge thanks to @boone for the walkthrough.

#8 @boonebgorges
5 years ago

  • Keywords 2nd-opinion added

krogsgard's 31251.patch includes unit tests and inline docs.

The patch looks good if we're agreed that we want to change the default behavior of 'show'. Passing show=display_name will work as before, but omitting 'show' (which covers 99% of the cases I've seen) will now show the new format Display Name (user_login). A scan of the plugins directory shows that dozens and dozens of plugins are using wp_dropdown_users() with the default value of 'show', and many appear to be using it on the front-end.

#9 @helen
5 years ago

I don't think we can change the default value - perhaps we can add a special one, or perhaps we should discuss something like tokenized templates (eek).

#10 @boonebgorges
5 years ago

Tokenized templates were actually my first thought, but yeah, eek. I can't think of another way to support it without an ad hoc parameter ('show=display_name_with_username'?).

Our choices are eek or ick.

#11 @krogsgard
5 years ago

A custom one seems fine to me, although then other core uses of the function would probably do well with their own changes to utilize it. Though there are only a handful of places its used. I personally would feel much more sensitive to the default change if it included an email address, whereas this is display + user. But I understand if it's not the way we'll go. I'd still like something, as right now it's pretty unusable with duplicate display names.

#12 @boonebgorges
5 years ago

I'd still like something, as right now it's pretty unusable with duplicate display names.

Yes - I think there's agreement that this should change in most core uses. The issue is that we shouldn't change the default behavior when used by third parties. So, whatever new parameter we go with, we would change some or all of the core uses of wp_dropdown_users() to use it.

This ticket was mentioned in Slack in #core by krogsgard. View the logs.


5 years ago

#14 follow-up: @krogsgard
5 years ago

I need name feedback on a revised patch. I'm changing it to not change the default show value for wp_dropdown_users(), but instead to add a param that is "display_name (username)".

I don't know what to call it. It's not really "all" but it is more... Any feedback of what other parts of core do for something like this?

New patch will also include the places in the admin that use the function and I'll update unit tests.

#15 in reply to: ↑ 14 ; follow-up: @boonebgorges
5 years ago

Replying to krogsgard:

I need name feedback on a revised patch. I'm changing it to not change the default show value for wp_dropdown_users(), but instead to add a param that is "display_name (username)".

I don't know what to call it. It's not really "all" but it is more... Any feedback of what other parts of core do for something like this?

I can't think of another place where this kind of thing is offered. I also can't think of a very beautiful name. Maybe 'display_name_with_login'?

Aside from the general unpleasantness of adding such an ugly parameter name, I'm worried about l11n. Are we reasonably sure that Display Name (user_login) makes sense in all languages? Perhaps we need a parameterized string that gets run through _x(): $format = _x( '%1$s (%2$s)', 'user dropdown display name with user login format' );? If the format were translation-friendly, I would feel a bit better about the fact that we're not introducing full tokenized format templates.

#16 in reply to: ↑ 15 ; follow-up: @SergeyBiryukov
5 years ago

Replying to boonebgorges:

Perhaps we need a parameterized string that gets run through _x(): $format = _x( '%1$s (%2$s)', 'user dropdown display name with user login format' );?

We do something like that in wp_ajax_autocomplete_user(), see [19897].

@ocean90, is there a way to see how many locales actually translate that string to something else?

#17 in reply to: ↑ 16 @ocean90
5 years ago

Replying to SergeyBiryukov:

@ocean90, is there a way to see how many locales actually translate that string to something else?

Only zh-tw and zh-cn are using something else for the brackets:

locale translation_0
en-ca %1$s (%2$s)
bs %1$s (%2$s)
sv %1$s (%2$s)
id %1$s (%2$s)
nn %1$s (%2$s)
he %1$s (%2$s)
pt-br %1$s (%2$s)
nb %1$s (%2$s)
pt %1$s (%2$s)
hr %1$s (%2$s)
it %1$s (%2$s)
so %1$s (%2$s)
cy %1$s (%2$s)
gd %1$s (%2$s)
ja %1$s (%2$s)
mk %1$s (%2$s)
tr %1$s (%2$s)
sl %1$s (%2$s)
zh-tw %1$s(%2$s)
bg %1$s (%2$s)
ca %1$s (%2$s)
fr %1$s (%2$s)
da %1$s (%2$s)
de %1$s (%2$s)
ro %1$s (%2$s)
pl %1$s (%2$s)
ug %1$s (%2$s)
es %1$s (%2$s)
pt %1$s (%2$s)
hu %1$s (%2$s)
is %1$s (%2$s)
ar %1$s (%2$s)
fi %1$s (%2$s)
de %1$s (%2$s)
ru %1$s (%2$s)
nl %1$s (%2$s)
es-cl %1$s (%2$s)
fa %1$s (%2$s)
ko %1$s (%2$s)
sr %1$s (%2$s)
sk %1$s (%2$s)
es-pe %1$s (%2$s)
mya %1$s (%2$s)
ckb %1$s (%2$s)
te %1$s (%2$s)
th %1$s (%2$s)
cs %1$s (%2$s)
et %1$s (%2$s)
eu %1$s (%2$s)
gl %1$s (%2$s)
gsw %1$s (%2$s)
zh-cn %1$s(%2$s)
el %1$s (%2$s)
me %1$s (%2$s)
az %1$s (%2$s)
en-gb %1$s (%2$s)
en-au %1$s (%2$s)
km %1$s (%2$s)
uk %1$s (%2$s)
ta-lk %1$s (%2$s)
vi %1$s (%2$s)
sq %1$s (%2$s)
haz %1$s (%2$s)
tl %1$s (%2$s)
ps %1$s (%2$s)
de-ch %1$s (%2$s)
lt %1$s (%2$s)
bcc %1$s (%2$s)
gsw %1$s (%2$s)
ga %1$s (%2$s)
ms %1$s (%2$s)
ne %1$s (%2$s)
hi %1$s (%2$s)
ky %1$s (%2$s)
es-mx %1$s (%2$s)
eo %1$s (%2$s)
rhg %1$s (%2$s)

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

This ticket was mentioned in Slack in #core by drew. View the logs.


5 years ago

#20 @DrewAPicture
5 years ago

  • Keywords 4.3-early added; 2nd-opinion removed
  • Milestone changed from 4.2 to Future Release
  • Type changed from defect (bug) to enhancement

This is squarely in enhancement territory, in my opinion. Just didn't have enough momentum leading up to beta 1. Let's take a look again in 4.3-early, and in the meantime, maybe come up with a workable argument name.

#21 @obenland
5 years ago

  • Owner set to boonebgorges
  • Status changed from new to assigned

#22 @obenland
5 years ago

  • Keywords 4.3-early removed
  • Milestone changed from Future Release to 4.3

#23 @obenland
4 years ago

  • Milestone changed from 4.3 to Future Release

#24 @boonebgorges
4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 35790:

Show user_login in Dashboard user dropdowns.

User dropdowns in wp-admin have traditionally shown the users' display names.
However, this causes ambiguity when users share display names. To correct this,
we now show the unique user_login in parentheses after the display name.

The new display_name_with_login value for the show parameter of
wp_dropdown_users() enables this functionality. The default value of show
has not been changed, for backward compatibility, but all instances of
wp_dropdown_users() in core wp-admin have been switched.

This changeset also reduces some duplicated logic when assembling a user list
when include_selected is true.

Props krogsgard, boonebgorges.
Fixes #31251.

#25 @netweb
4 years ago

  • Milestone changed from Future Release to 4.5
Note: See TracTickets for help on using tickets.