Use getDisplayName() for user names consistently

This does not qualify as critical as far as I know.

There will be more tests added in follow up cases.

If you know there are more relevant cases to be tested, why not add them now?

1. +++ b/core/modules/user/src/Tests/UserDisplayNameTest.php
   @@ -0,0 +1,68 @@
   +    // Login after the alter hook has been enabled or the username is shown.
   

   'or the username is shown.' I don't know what is meant by this.

2. +++ b/core/modules/user/src/Tests/UserEntityCallbacksTest.php
   @@ -56,7 +59,7 @@
   -    $this->assertEqual($this->anonymous->getUserName(), '', 'The raw anonymous user name should be empty string');
   +    $this->assertEqual($this->anonymous->getUsername(), '', 'The raw anonymous user name should be empty string');
   

   I don't know what is changed here, but it seems to be unrelated.

I am sorry I gave you the impression I did not read the patch, because I have actually read the patch thoroughly, which raised my questions. What makes you think that I didn't read the patch?

There will be more tests added in follow up cases.

If you know there are more relevant cases to be tested, why not add them now?

I don't think i can answer this question by reading the patch. But the question is valid in my opinion. If you know about more relevant test cases, they should be added no?

Your comment // Login after the alter hook has been enabled or the username is shown. just makes no sense to me. When I look at the code a user is logged in after the hook is enabled. The hook being enabled is obvious and does not require a comment, but nowhere is a page being requested or a render function being called before that comment line. So how can a username be shown?

As for the last question. A changed line ending is the only reason I can think of which would cause that change. Other than that both lines are identical and not changing any functionality. They are therefor unrelated and should be removed.

At first I felt really offended by the way you (aggressively) commented on my review. But after counting to 10 and assuming you might just be having a bad day, I've chosen to answer openly en truthfully like I did above. I do however feel that I should inform you about the way your comment made me feel, so you can maybe adjust your way of responding in the future.

I linked follow up patches. These will add more patches. I can delete my comment if it helps you ignoring it.

I overlooked the Meta issue. With that context I understand the comment and I agree the additional test coverage should be part of their respective issues.

That is because you have not understood the patch. One line before is the hook enabled. It is just a note that the order of both lines is important.

I understand the patch perfectly and also know the order of those lines are important. The comment in it's current form however only adds confusion instead of clarity. How about this?
// We must login after the alter hook as been enabled or the username will be shown instead of the display name.

The other changed line changes getUsername to getUserName. The function in the class is named getUserName and not getUsername.

I have seriously been staring at these two lines for several minutes, both before and after my initial comment, but totally missed that. Thanks for clarifying.

If you improve the comment I'll RTBC the patch.

I'm not sure why it didn't work, but when I applied your patch I ended up with a missing closing brace. Rerolled with the brace.

Discussed this with @catch, @alexpott, @xjm, and @Cottser, and we agree this is Major.

This is a regression from Drupal 7, and explicitly violates the docs of AccountInterface::getAccountName(), which says Only display this name to admins and to the user who owns this account, whereas "access user profiles" is not an admin-level permission.

+++ b/core/modules/user/src/Tests/UserDisplayNameTest.php
@@ -0,0 +1,69 @@
+ * Tests that display name is shown everywhere.

This doesn't test that the display name is shown everywhere.

Also do we really need a new test, or is there an existing login test we could add an assertion to?

Please read the comment I posted again.

The added test only tests one place, we have other tests for that page, so:

Also do we really need a new test, or is there an existing login test we could add an assertion to?

I'm not sure but I think you may not be understanding what @catch meant.

I don't think he's saying "test everywhere, make 100 assertions all over the place". I think he's saying "don't create a new test, take 1 of the existing login tests for that user/ page and add an assertion to that instead".

we [already] have other tests for that [user/] page

is there an existing login test [from among these other tests] we could add an assertion to

However, I could not see a test in the user module that tested the basic contents of the user/userID page. I assume this is my own ignorance and I've overlooked something, but if you can't find the file with the basic tests for this page either, maybe you could report that to @catch and see what he advises. Surely is must exist somewhere.

Here a #61's reroll.

I will try to fix the test which are still failing.

I've been working today on this.

+++ b/core/profiles/testing/testing.info.yml
@@ -9,6 +9,8 @@ dependencies:
+  # Make sure DisplayName is always enabled and properly tested.
+  - user_hooks_test

I do not agree with this, even if it is stupid like #30 said if this module is enabled by default this will make the output in certain tests be unexpected and will confuse developers when they write new tests because some <em> tags will appear in the DisplayName.

If every module which uses display name enable this module at least it will give an insight why the displayname has some extra tags.

I will try to provide a patch which not require this module by default.

Hi hass

Hey, the sense of this patch is to show WHERE dispayname is broken. This is why i wrote this. Developers need to expect the display name AND html.
Currently they often do not and THIS is the problem!!!

You are right, I left the user_hooks_test in the testing.info.yml file so we know which tests we need to fix (thanks!)

I hit a wall here:

    \Drupal::state()->set('user_hooks_test_user_format_name_alter_safe', TRUE);
    $this->drupalPostForm('node/' . $this->node->id(), $edit, t('Preview'));
    $this->assertTrue($this->webUser->getDisplayName() instanceof MarkupInterface, 'Username is marked safe');
    $this->assertNoEscaped($this->webUser->getDisplayName());
    $this->assertRaw($this->webUser->getDisplayName());
    \Drupal::state()->set('user_hooks_test_user_format_name_alter_safe', FALSE);

Basically, the test expect the "<em></em>" be wrapping the display name BUT if the displayname is longer than 20 characters the getDisplayNameTruncated will remove the last leaving something like: <em>Firstname3… which makes me wonder if the getDisplayNameTruncated should strip the html tags before to truncate the string and if we should rewrite the test above.

I attached my progress so far.

1. that looks strange... that should be installed by default

   Yeah, it is weird, not sure why in this case is not there by default, I will check why.

2. How is it possible that $name is no string?

   That is because of this:

   if (\Drupal::state()->get('user_hooks_test_user_format_name_alter_safe', FALSE)) {
           $name = SafeMarkup::format('<em>@display-name</em>', array('@display-name' => 'Firstname' . $uid . ' Lastname' . $uid));
   }
   

   SafeMarkup::format() returns an instance of MarkupInterface

3. I would better only strip on the display name

   True, I will fix that in my next patch.

Hi,

Just run into this one with some tests on a site with the a changed display name.

Reading up, I was wondering - honest question, I've not delved deeply into the different usages of DisplayName - could the issue and patch be broken into two (or three)? One of them RTBC as lots of them are trivial fixes that might as well go in, and one detailing the problems with different usages.

I agree changing the active code without tests to cover it wouldn't be good. Could those case be spun off into another issue that actually details what the problem is. But plenty of this patch should be good no?

The core _tests_ are presently broken. If you implement a change to getDisplayName() there's red. There are tests that use getUserName() in them, which pass only because the output is the same as getDisplayName(); but they should be using getDisplayName() because that's being put into the strings. This patch includes those changes, can't see any reason they shouldn't go in already. Committing changes to the tests already would be an improvement?

Also if there are some changes to the active code, cleaning up other places that it's wrong - with tests - would be an improvement too?

Then it's the complicated bits that could be fleshed out? Like I say, a thought.

Interesting question. Guess to prove the tests fail you have to implement a test module that changes getDisplayName so it's not the same as getUserName.

Anyway if it's not going to speed up getting fixes in, doesn't matter.

This might be enough of a change to bump up to 8.3.x, but it's a major bug so leaving it at 8.2.x.

I think it's a reviewable size as-is, though it is big.

Just a couple things related to the truncated name:

1. +++ b/core/lib/Drupal/Core/Session/AccountInterface.php
   @@ -146,6 +146,18 @@ public function getAccountName();
      /**
   +   * Returns the truncated display name of this account.
   +   *
   +   * @see getDisplayName()
   +   *
   +   * @return string|\Drupal\Component\Render\MarkupInterface
   +   *   Either a string that will be auto-escaped on output or a
   +   *   MarkupInterface object that is already HTML escaped. Either is safe
   +   *   to be printed within HTML fragments.
   +   */
   +  public function getDisplayNameTruncated();
   

   Either add a length parameter or document the truncated length. But really add a length parameter that defaults to 20. :-)

2. +++ b/core/modules/user/user.module
   @@ -471,10 +471,9 @@ function template_preprocess_username(&$variables) {
   +  $name  = $account->getDisplayNameTruncated();
   +  $variables['name_raw'] = $account->getDisplayName();
      if (Unicode::strlen($name) > 20) {
   -    $name = Unicode::truncate($name, 15, FALSE, TRUE);
        $variables['truncated'] = TRUE;
   

   If you have a way to pass in the truncated length, then you can do that here and know that 20 is the biggest non-truncated name without trusting.

Here's a straight re-roll of #67.

OK, so #2767787: Allow custom truncate username settings is a follow-up. That's a D7 issue, btw.

Still needs passing tests here.

Mohit_aghera,

great that you want to contribute to this issue, but there is no need to assign this to you.
Even though the issue tracker technically allows people to assign issues, this feature is generally not used in order to encourage everybody to contribute.
And as you can see in this case: there are several people actively working on the issue.

If you want to contribute: please write that into a comment. Don't claim issues for yourself. I'll unassign you.

(And to anybody committing this later: Don't credit me in the issue commit. I'm just writing a note.)

Here is straight re-roll of #78 for initial testing

Uploading patch with initial try to fix test case failures.

Updating relevant method names.

Added missing namespace which was causing fatal errors.

Re-rolling patch again as it was not getting applied after recent test case changes.

Thank you for your contribution. Beware of duplication with #2801645: Use \Drupal\user\UserInterface::getDisplayName() on user pages instead of the plain User::getUsername() , though.
I'm not confident enough to decide which of your issues should be closed in favor of the other. Could you have a look there and see how you can converge?

Here's an updated patch for 8.4.x-dev.

Applied to 8.5.x as this won't go into 8.4 anymore.

This issue seems to have morphed into adding truncation to usernames in core. Has it been scope creeped? Can that this problem be fixed without the API addition?

Per #124 this needs a CAREFUL reroll of #113. Some previous attepmts to reroll have not caught all the fixes in the patch. A successful reroll should only have 8 test fails.

Re-rolled. I will check back if this does not have the expected 8 test fails.

Close, but not the expected 8 test fails. I'll investigate.

@hass why does this need to be truncated anywhere?

Couldn't you use text-overflow: ellipsis; in CSS and call it a day?
https://css-tricks.com/snippets/css/truncate-string-with-ellipsis/

And you can use a minimum width to hold the space with character spacing:
min-width: 20ch

Edit: Assuming this is for UI purposes. Please correct me if my assumption is incorrect.
https://caniuse.com/#search=text-overflow

Seems like a much quicker approach if the issue is UI to do the presentation with CSS. It may not go into stable/classy(maintainer must decide) but could be put into core, Seven and Bartik.

Here's a POC with the user table and some fake names.
https://jsfiddle.net/5r8qe42t/1/

Manual testing for CSS changes, aka Screenshots.

I'll see if one of the theme system maintainers can weigh in on #132 as a viable direction.

re: #132, I needed to do something similar a while back to only show first two letters of language switcher options on small screens (because of space issues), so EN | GA on small screens and ENGLISH | GAEILGE on larger ones.

I looked at using the ch css width to show only two characters, but it turns out that only works for mono-spaced fonts, which might be an issue if we add it to Drupal core. In the end, I solved it with a small bit of JS to search the string, split it at 2 characters, and then just show those on small screens.

Here's a stackoverflow issue that I came across - https://stackoverflow.com/questions/35328019/css-display-only-the-first-...

There's also a (partial support) issue with it in IE11 -

IE supports the ch unit, but unlike other browsers its width is that specifically of the "0" glyph, not its surrounding space. As a result, 3ch for example is shorter than the width of the string "000" in IE.

https://caniuse.com/#search=ch

@hass,

I don't think it is a different issue.

From the code supplied in #132, it specifically states

 .username {
   min-width: 10ch;
   width: 100%;
 }
 
 
.views-field-name {
  max-width: 20ch;
}

Unless, I am reading this wrong, we are saying that the user name will be at least 10ch wide (10 monospaced characters) and at most 20ch (20 monospaced characters). BUT, if the font being used is not monospaced, then 20ch may cut off characters mid-point through a character (an "o" might end up looking like a "c").

In my example, I only need 2 characters, but this seems to be suggesting that we need up-to-20 and no more than 20 (which makes it look very similar to my issue (solved with JS)).

I get the point, but what I am saying is that we might end up cutting off letters/characters mid-way through the character itself. Leaving us with something like this (presuming the user name was longer than yours is):

I am basing my info on the link to stackoverflow and caniuse from my previous comment.

StackOverflow:

Unfortunately this works only with monospace fonts and not in older browsers.

- https://stackoverflow.com/questions/35328019/css-display-only-the-first-...

Can I Use:

IE supports the ch unit, but unlike other browsers its width is that specifically of the "0" glyph, not its surrounding space. As a result, 3ch for example is shorter than the width of the string "000" in IE.

- https://caniuse.com/#search=ch

Here's a basic fiddle showing it in action:
https://jsfiddle.net/3vwogyjs/1/

here a version with ellipsis and yes it totally works!

I really like this approach.

https://jsfiddle.net/e3ozc124/

Excellent. Looks like we might have a solution so.

here a reroll of #126.

I will provide a patch with the CSS trick and without the API addition in my next comment to keep this moving.

I found a problem with the new approach :-/

When the account is not verified the module appends a text letting the user know with this new approach that text is hidden.

This can be fixed if we add an extra tag to wrap the username and left the extra text outside of this tag but not sure if we can just change the markup at this point:

Without the patch:

With the patch:

Let's see what the testbot says.

is this issue adding a display name field?

my recommendation, which I guess is similar to this, was to change user name to user login, and then add a new user name field for display.
https://www.drupal.org/project/drupal/issues/295440

The patch at #150 applies correctly to Drupal core 8.5.3, but it doesn't apply any longer to Drupal core 8.5.4, released yesterday.

I rerolled the #150 for D8.5.4.

I rerolled the #156 for D8.5.5.

1. +++ b/core/lib/Drupal/Core/Session/UserSession.php
   @@ -174,6 +178,23 @@ public function getDisplayName() {
   +    $display_name = $this->getDisplayName();
   +
   +    // If $display_name is an instance of MarkupInterface then convert it to
   +    // string to truncate it.
   +    $name = ($display_name instanceof MarkupInterface) ? $display_name->__toString() : $display_name;
   +    if (Unicode::strlen($name) > 20) {
   +      $name = Unicode::truncate((string) $name, 15, FALSE, TRUE);
   +    }
   +    $name = ($display_name instanceof MarkupInterface) ? Markup::create($name) : $name;
   +
   +    return $name;
   

   Truncated markup objects is super tricky. What happens if getDisplayName has added markup to the string - for whatever reason. This can end up in breaking the HTML. I think maybe we need to use \Drupal\Component\Render\PlainTextOutput::renderFromHtml() here to truncate safely. In fact, this makes me wonder if we shouldn't add a method to MarkupTrait to do this for us. Something like:

     public function truncate($max_length, $wordsafe = FALSE, $add_ellipsis = FALSE, $min_wordsafe_length = 1) {
       $string = PlainTextOutput::renderFromHtml($this->string);
       // @todo can we return an object of the same class?!?!?
       return Markup::create(Unicode::truncate($string, $max_length, $wordsafe, $add_ellipsis, $min_wordsafe_length));
     }
   

2. +++ b/core/modules/user/src/Tests/UserPasswordResetTest.php
   @@ -90,7 +90,7 @@ public function testUserPasswordReset() {
   -    $subject = t('Replacement login information for @username at @site', ['@username' => $this->account->getUsername(), '@site' => $this->config('system.site')->get('name')]);
   +    $subject = t('Replacement login information for @username at @site', ['@username' => $this->account->getDisplayName(), '@site' => $this->config('system.site')->get('name')]);
   

   I'm not sure that login information should do use the display name. Looking at the docs for getAccountName()

      *   An unsanitized plain-text string with the name of this account that is
      *   used to log in. Only display this name to admins and to the user who owns
      *   this account, and only in the context of the name used to log in. For
      *   any other display purposes, use
      *   \Drupal\Core\Session\AccountInterface::getDisplayName() instead.
   

   I think when we're dealing with login information we should use getAccountName().

+++ b/core/modules/comment/tests/src/Kernel/CommentFieldAccessTest.php
@@ -212,12 +212,12 @@ public function testAccessToAdministrativeFields() {
-          '@user' => $set['user']->getUsername(),
+          '@user' => $set['user']->getDisplayName(),
...
-          '@user' => $set['user']->getUsername(),
+          '@user' => $set['user']->getDisplayName(),
           '@state' => $may_update ? 'can' : 'cannot',

@@ -229,7 +229,7 @@ public function testAccessToAdministrativeFields() {
-        '@user' => $set['user']->getUsername(),
+        '@user' => $set['user']->getDisplayName(),

@@ -251,13 +251,13 @@ public function testAccessToAdministrativeFields() {
-          '@user' => $set['user']->getUsername(),
+          '@user' => $set['user']->getDisplayName(),
...
-          '@user' => $set['user']->getUsername(),
+          '@user' => $set['user']->getDisplayName(),

@@ -272,12 +272,12 @@ public function testAccessToAdministrativeFields() {
-          '@user' => $set['user']->getUsername(),
+          '@user' => $set['user']->getDisplayName(),
...
-          '@user' => $set['user']->getUsername(),
+          '@user' => $set['user']->getDisplayName(),

@@ -299,7 +299,7 @@ public function testAccessToAdministrativeFields() {
-          '@user' => $set['user']->getUsername(),
+          '@user' => $set['user']->getDisplayName(),

I think these should all be getAccountName() - this is a test for what that user account can do.

After thinking about this some more I think we should complete the deprecation and convert everything to getAccountName() in #2787871: Properly deprecate getUserName() and use getAccountName() instead and then this issue can focus on when and where to use getDisplayName()

1. @hass I don't want to demotivate you but this patch is doing three things which is why it is taking ages to get done. We should try to split these up so that we can get the goodness of this work in to core. The three things are:
   • Removing usage of getUsername() - let's do that in #2787871: Properly deprecate getUserName() and use getAccountName() instead
   • Adding new functionality to truncate usernames - we probably should add generic functionality to Markup objects to do that safely - also we should really discuss whether we can truncate usernames if the display version contains html or whether we should allow it but add documentation to the hook to tell people to not add html here because the display name is truncated.
   • Converting places to use getDisplayName() correctly and ensuring we have test coverage

   All three of these things are great things to do but doing them in the same issue means that the patch is large, hard to review and often has further scope creep (eg replace format_string() usage).

2. +++ b/core/modules/content_translation/tests/src/Functional/ContentTranslationWorkflowsTest.php
   @@ -154,7 +154,7 @@ public function testWorkflows() {
   -    $args = ['@user_label' => $user->getUsername()];
   +    $args = ['@user_label' => $user->getDisplayName()];
   

   This is used in a test for an assertion message about permissions should be getAccountName()

3. +++ b/core/modules/simpletest/src/WebTestBase.php
   @@ -294,7 +295,7 @@ protected function drupalLogin(AccountInterface $account) {
   -    $pass = $this->assert($this->drupalUserIsLoggedIn($account), format_string('User %name successfully logged in.', ['%name' => $account->getUsername()]), 'User login');
   +    $pass = $this->assert($this->drupalUserIsLoggedIn($account), new FormattableMarkup('User %name successfully logged in.', ['%name' => $account->getDisplayName()]), 'User login');
   

   This change is unnecessary this is a text assertion message in tests relating to whether the account is logged in.

4. +++ b/core/modules/tracker/src/Controller/TrackerUserTab.php
   @@ -22,7 +22,7 @@ public function getContent(UserInterface $user) {
   -    return $user->getUsername();
   +    return $user->getDisplayName();
   

   +1 nice find.

5. +++ b/core/modules/user/tests/modules/user_hooks_test/user_hooks_test.module
   @@ -11,12 +11,16 @@
   +  if (\Drupal::state()->get('user_hooks_test_user_format_name_alter', TRUE)) {
   

   I like this - making this always on makes heaps of sense.

6. +++ b/core/modules/user/tests/src/Functional/UserAdminListingTest.php
   @@ -93,6 +96,8 @@ public function testUserListing() {
   +
   +    \Drupal::state()->set('user_hooks_test_user_format_name_alter', TRUE);
   

   This shouldn't be necessary - the test site is completely torn down and does not affect the next test.

7. +++ b/core/profiles/testing/testing.info.yml
   @@ -9,6 +9,8 @@ dependencies:
   +  # Make sure DisplayName is always enabled and properly tested.
   +  - user_hooks_test
   

   +1,000,000 really great idea.

@hass but no of this is simple. For example:

+++ b/core/modules/user/user.module
@@ -1281,7 +1281,7 @@ function user_form_process_password_confirm($element) {
-      'username' => \Drupal::currentUser()->getUsername(),
+      'username' => \Drupal::currentUser()->getDisplayName(),

This one is more complex. This is used by the password JS to ensure you don't match your login name so - getUsername() should definitely be here BUT also I think the password should not match the display name either. However, this change as it stands is incorrect. And needs a separate issue with new tests to change how this works to be able to have multiple usernames or something like that.

This is why I proprose breaking this up into more manageable pieces and doing the deprecation and getUsername -> getAccountName first because then the noise in this patch will be lessened. If we get #2787871: Properly deprecate getUserName() and use getAccountName() instead done I'm happy to re-roll this on top and and document all the places where getDisplayName() should be used and why.

I rerolled the #157 for D8.6.1

This patch needs a major re-rolled now that #2787871: Properly deprecate getUserName() and use getAccountName() instead has landed.

Here's a reroll.

The are a number of changes here that are unnecessary. And other that need discuss as far as I can see.

1. +++ b/core/lib/Drupal/Core/Session/UserSession.php
   @@ -175,6 +179,23 @@ public function getDisplayName() {
   +  public function getDisplayNameTruncated() {
   +    $display_name = $this->getDisplayName();
   +
   +    // If $display_name is an instance of MarkupInterface then convert it to
   +    // string to truncate it.
   +    $name = ($display_name instanceof MarkupInterface) ? $display_name->__toString() : $display_name;
   +    if (Unicode::strlen($name) > 20) {
   +      $name = Unicode::truncate((string) $name, 15, FALSE, TRUE);
   +    }
   +    $name = ($display_name instanceof MarkupInterface) ? Markup::create($name) : $name;
   +
   +    return $name;
   +  }
   

   This logic can be a little simpler. Done that in the patch attached.

2. +++ b/core/modules/simpletest/src/WebTestBase.php
   @@ -294,7 +294,7 @@ protected function drupalLogin(AccountInterface $account) {
   -    $pass = $this->assert($this->drupalUserIsLoggedIn($account), format_string('User %name successfully logged in.', ['%name' => $account->getAccountName()]), 'User login');
   +    $pass = $this->assert($this->drupalUserIsLoggedIn($account), new FormattableMarkup('User %name successfully logged in.', ['%name' => $account->getDisplayName()]), 'User login');
   

   This type of change on an assertion message is not necessary. In fact I'd argue that this gets in the way of knowing which user has successfully logged in. And there are a number of other test changes like this that I think should be dropped. For example all the changes to CommentFieldAccessTest

3. +++ b/core/modules/user/tests/src/Functional/UserAdminTest.php
   @@ -71,20 +71,20 @@ public function testUserAdmin() {
   -    $this->assertNoText($user_a->getAccountName(), 'User A not on filtered by perm admin users page');
   -    $this->assertText($user_b->getAccountName(), 'Found user B on filtered by perm admin users page');
   -    $this->assertText($user_c->getAccountName(), 'Found user C on filtered by perm admin users page');
   +    $this->assertNoText($user_a->getDisplayNameTruncated(), 'User A not on filtered by perm admin users page');
   +    $this->assertEscaped($user_b->getDisplayNameTruncated(), 'Found user B on filtered by perm admin users page');
   +    $this->assertEscaped($user_c->getDisplayNameTruncated(), 'Found user C on filtered by perm admin users page');
   

   I'm not totally convinced that name listed on the admin users page should be the display name. I think there is a case that admins need the real username that a user logs in with.

4. +++ b/core/modules/user/tests/src/Functional/UserCancelTest.php
   @@ -84,7 +84,7 @@ public function testUserCancelChangePermission() {
   -    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getAccountName()]), 'User deleted.');
   +    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getDisplayName()]), 'User deleted.');
        $this->assertFalse(User::load($account->id()), 'User is not found in the database.');
   
   @@ -198,7 +198,7 @@ public function testUserBlock() {
   -    $this->assertRaw(t('%name has been disabled.', ['%name' => $account->getAccountName()]), "Confirmation message displayed to user.");
   +    $this->assertRaw(t('%name has been disabled.', ['%name' => $account->getDisplayName()]), "Confirmation message displayed to user.");
   
   @@ -255,7 +255,7 @@ public function testUserBlockUnpublish() {
   -    $this->assertRaw(t('%name has been disabled.', ['%name' => $account->getAccountName()]), "Confirmation message displayed to user.");
   +    $this->assertRaw(t('%name has been disabled.', ['%name' => $account->getDisplayName()]), "Confirmation message displayed to user.");
   
   @@ -352,7 +352,7 @@ public function testUserAnonymize() {
   -    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getAccountName()]), "Confirmation message displayed to user.");
   +    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getDisplayName()]), "Confirmation message displayed to user.");
   
   @@ -471,7 +471,7 @@ public function testUserDelete() {
   -    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getAccountName()]), "Confirmation message displayed to user.");
   +    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getDisplayName()]), "Confirmation message displayed to user.");
   
   @@ -490,12 +490,12 @@ public function testUserCancelByAdmin() {
   -    $this->assertRaw(t('Are you sure you want to cancel the account %name?', ['%name' => $account->getAccountName()]), 'Confirmation form to cancel account displayed.');
   +    $this->assertRaw(t('Are you sure you want to cancel the account %name?', ['%name' => $account->getDisplayName()]), 'Confirmation form to cancel account displayed.');
   ...
   -    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getAccountName()]), 'User deleted.');
   +    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getDisplayName()]), 'User deleted.');
   
   @@ -518,12 +518,12 @@ public function testUserWithoutEmailCancelByAdmin() {
   -    $this->assertRaw(t('Are you sure you want to cancel the account %name?', ['%name' => $account->getAccountName()]), 'Confirmation form to cancel account displayed.');
   +    $this->assertRaw(t('Are you sure you want to cancel the account %name?', ['%name' => $account->getDisplayName()]), 'Confirmation form to cancel account displayed.');
   ...
   -    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getAccountName()]), 'User deleted.');
   +    $this->assertRaw(t('%name has been deleted.', ['%name' => $account->getDisplayName()]), 'User deleted.');
   

   Similarly I'm not sure that these actions should use the display name. This is tricky because many of these already use the display name.

5. +++ b/core/profiles/testing/testing.info.yml
   @@ -9,6 +9,8 @@ install:
   +  # Make sure DisplayName is always enabled and properly tested.
   +  - user_hooks_test
   

   I think this is a very good idea but I'm scared that this is going to cause a lot of disruption for contrib and sites with automated tests.