Rename 'Authenticated user' and 'anonymous user' so they are clearer

I'm for changing the labels as well.
anonymous is ok in that it makes sense they are anonymous in the way I (site owner) doesn't know anything about them.

I would change authenticated user to registered user. This suggested they are registered and have had to supply the information requested to become a "user" "member" "visitor" and have the abilities (permissions) allowed for people who have registered.

This also deals with the issue that it applies to everyone registered, that anyone registered has the role registered and received those permissions. The word registered would apply to anyone that has a user account. Authenticated is a bit vague because the meaning of authenticated isn't as simple as registered.

What causes someone to be authenticated?
What causes someone to be registered?

I think more new people would be able to answer the 2nd question easier then the 1st.

I'm ambivalent about "authenticated" but I too feel that "anonymous" is a misnomer; in fact I changed "(not verified)" to "(visitor)" on my own site. This needs to reconsidered for 8.x now.

Its a bit late to be changing these kinds of strings for Drupal 8.

Fortunately Drupal 7 and 8 have the anonymous role label ("The name used to indicate anonymous users") field in user settings to address the anonymous side of things.

Could we change the anonymous role label default from "Anonymous" to "Visitor"?

Also, if the anonymous role label is configurable, could we make the authenticated role label configurable in the same way, and change its default to "Logged-in user"?

It wouldn't just affect the role label. You would have to update a lot of l10n string which include "authenticated" terminology.

You'd have to do it all at once (Drupal 9) for default strings to be consistent.

Attaching a patch to change the anonymous role label default from "Anonymous" to "Visitor" in 8.3.x. Not sure if this particular aspect should be split off into separate issue.

Hmm... although the help text still refers to the old names:

It is recommended to order roles from least permissive (for example, Anonymous user) to most permissive (for example, Administrator user). Users who are not logged in have the Anonymous user role.

... I see your point @dpi

Out of curiosity, do we have policies on what kinds of interface text, string freezes, etc. can occur during point releases (x.y -> x.(y+1))?

If you were changing the default label then the ID's should be changed to match as well. ID's cant be changed until the next major version.

Considering how easy it is to just change the role label, its much easier to defer to 9.x

Would love to see this. "Authenticated" is definitely a stuffy Drupalism. "Visitors" and "Logged in users" seem much clearer.

Go for it I say!

I can get this done today.

I changed the installation yml files to change the default labels for the Authenticated user role and Anonymous user role to Logged-in user and Visitor respectively.

Adding some tags after hearing about this issue.

Next steps would be to make sure the issue summary is up-to-date and to fix the test fails.

MrMason is going to be at the Nashville 2018 sprint on Friday.

We are trying to work on this at the mentored core sprint, Nashville 2018

We are trying to work on this at the 1st timers core sprint, Nashville 2018

This is the new patch for 8.6.

We are trying to work on this at the 1st timers core sprint, Nashville 2018

Thanks for "my team" at the Mentored Core Spring in DrupalCon Nashville 2018 to work on this together: Tracy (https://www.drupal.org/u/thummel) & TaoStyle (https://www.drupal.org/project/drupal/issues/479708#comment-12570111). Special thanks to MrMason (https://www.drupal.org/u/mrmason) for walking us through the process and generating the latest patch for 8.6.

The patch in comment #18, worked for me. However I agree with @dpi that there are other instances of the terms 'Anonymous user' and 'Authenticated user' which will need to be updated as well. Let's do this for version 9.

Sure? #12 says we can change strings. Drupal 9 won't be there very soon. If this needs more work to change all instances of these terms we can still do that. Thanks for working on this!

Playing musical chairs with the issue status: back to where it was before #29.

This is a headache for our users. How massive can the changes be? Because Drupal use the anonymous word in many places. I will try to show the word "Visitors" only in labels and keep anonymous in keys.

Fixing test. This is a complex issue because if we want to complete replace the use anonymous by visitor the changes can be massive.

This patch will solve the issue.

Reroll patch from #35 for 8.7.x

Using patch #39 to fix test errors in the files InstallerTranslationMultipleLanguageKeepEnglishTest and InstallerTranslationMultipleLanguageTest

Commiting a patch, please review.

Tagging for upcoming contribution days.

working on it.

Uploading the patch with only label configuration changes, Lets find out where and all tets getting failed. Then will fix those tests,

Changing according to proposed solution,

Authenticated user" role label changes to "Visitor" (singular)
"Anonymous user" role label changes to "Logged-in user" (singular)

Hello , We are at ContributionWeekend and we are going to review the tests errors.

Sounds Awesome, If we can identify and fix those test errors. then it will be nice way to progress....

Tagging for DrupalNorth 2019

I created patch for change the default labels for the Authenticated user role to Logged-in user and Anonymous user role to Visitor please review.

I have worked on renaming the user names and created a patch for same.Please review.

The test result for the latest patch in #61 says "Build successful", but actually if you click through to the test results you will find that every single test failed.

The reason is this:

+++ b/core/modules/user/config/install/user.role.anonymous.yml
@@ -1,8 +1,8 @@
 langcode: en
 status: true
 dependencies: {  }
-id: anonymous
-label: 'Anonymous user'
+id: visitor
+label: 'visitor'

The correct file name for a config file with id => "visitor" (the new ID of the role) is not user.role.anonymous.yml. It must be named user.role.visitor.yml. The same goes for the authenticated role. Drupal cannot successfully install with these file names. If you dig into the test fails, you will see failures like this:

The configuration name "user.role.anonymous" does not match the ID "visitor"

/var/www/html/core/lib/Drupal/Core/Config/ConfigInstaller.php:373

What I don't understand is why on #48 someone decided to just change the labels and not include the test fixes that had already been in previous patches. And then why on #58 someone apparently thought it was OK to start completely over (but ended up with the same patch), and then why on #61 someone decided to change the IDs as well as the labels. We should only be changing the labels, not the IDs.

I recommend that we delete all comments and patches after #46 because they are all unproductive, and we can go back to the last/best patch on #45 and go from there. The extra patches in between are worse than the one on #45 and should just be ignored.

As suggested in #62, rerolled #45 to the current version. Please suggest further changes.

Thanks! Now we're on the right track. The next changes would be:

a) See if the words "Authenticated" and "Anonymous" are used anywhere else in Drupal Core and change them to the new wording. The command-line "grep -R" should be useful for searching the entire codebase, or maybe an IDE can help? Not sure.

b) Whatever changes to tests are necessary so that the automated tests pass. Right now there are 6 tests failing, which is a lot better than the previous patch (which had all 3000+ tests failing). So, you'll need to look at those test fails (probably run the tests on your local site), figure out why they are failing (probably because they are looking for the words "anonymous" or "authenticated" and they are not there in the UI any more), and fix them.

c) Probably the changes in (a) will result in more failures, so you'll have to return to (b) to fix them.

Thanks for the review, will do these changes.

Replaced the 'authenticated' for now, if works fine then will replace 'anonymous' as well in some time.

I have replaced all authenticated users with logged-in users. Check if it works. As #67 failed to apply so i have recreated it. if it works i will recreate including anonymous as well.

The patch #68 needs reroll.

Also, you do not need to replace the word "authenticated" (and anonymous) in comments. You only need to replace it in text that a Drupal user would see in the user interface. So these changes are unnecessary, among others:

-    # collector. When a session is deleted, authenticated users are logged out,
+    # collector. When a session is deleted, logged-in users are logged out,
...
- * Cookie", authenticated users would also be served the anonymous page from
+ * Cookie", logged-in users would also be served the anonymous page from

There seem to be some totally unrelated changes in this patch too, like

--- /dev/null
+++ b/core/lib/Drupal/Component/Annotation/Doctrine/DocParser.php

So... basically that last patch is not very good, besides the fact that it does not apply. Make sure your starting point is Drupal 8.9.x, and that only changes you meant to put in the patch are in the patch.

@jhodgdon Thanks for the suggestion. I will work on that.

Recreated patch for renaming. Please review.

This is not progress. There was a patch in #45 that fixed some of the tests. The patch in #63 rerolled this to the current version. This latest patch misses all of that progress.

This is very frustrating. It really looks like several people on this issue are not even reading the comments, not looking at what has already been done, just trying to make quick patches to get issue credit. It wastes the time of others to review when you do not take the time to be careful. I am really tempted to unpublish all of the comments where people didn't build on what had already gone before...

I have Updated the patch from #63 and updated the failed test cases.

The tests on your latest patch haven't run yet (due to problems on the testing server), but I took a look at the interdiff/patch and I have one concern:

+++ b/core/modules/system/tests/src/Functional/Entity/EntityReferenceSelection/EntityReferenceSelectionAccessTest.php
@@ -341,8 +341,8 @@ public function testUserHandler() {
       ],
       [
         'arguments' => [
-          ['Anonymous', 'CONTAINS'],
-          ['anonymous', 'CONTAINS'],
+          ['Visitor', 'CONTAINS'],
+          ['visitor', 'CONTAINS'],

The lower-case "anonymous" should still be there, I think? We are changing the UI label of the anonymous user account ("Anonymous" to "Visitor"), not the machine name.

All the tests got passed.
Also, I just run the test after changing "visitor" back to "anonymous", there is one failure.

Hm. That is concerning... I am not sure why that would be. It seems like a bug in the test, if that change needs to be made?

It seems like a product manager review could be more valuable than a framework or release manager review.

I don't think there are any more actionable tasks for a Novice. @seeallie updated the issue summary and that still looks accurate to the scope of the issue.

Regarding the question from @jhodgdon,

+++ b/core/modules/system/tests/src/Functional/Entity/EntityReferenceSelection/EntityReferenceSelectionAccessTest.php
@@ -341,8 +341,8 @@ public function testUserHandler() {
-          ['Anonymous', 'CONTAINS'],
-          ['anonymous', 'CONTAINS'],
+          ['Visitor', 'CONTAINS'],
+          ['visitor', 'CONTAINS'],

I believe that this test is asserting the case insensitivity of entity queries, if I recall correctly.

The test here is fairly confusing as to why its testing those arguments in the entity reference handlers and that could have used a comment to explain the test.

I'm not sure if that's in scope here or not though.

It seems to me that adding one line of comments that explains this, in order that the patch can be reviewed properly, is within the scope of this issue. Because otherwise it just looks like the test failed and someone made this change in order to pass, but really there's a bug in the test.

Needs Re-roll.

Rerolled

Fixing test, Please review.

Rerolled patch #88

Anushri, all, great! I'd call this ready to RTBC but a slight regression in the last re-roll,

// Test changing the comment author to "Anonymous".

the comment should also have "Anonymous" changed to "Visitor" still.

@mlncn Done with the changes you advises, Please have a look.

Tested this patch on 9.2.0-dev installation.

After applying the patch from #93, run drush cim --partial --source=core/modules/user/config/install and drush cr.

Checked the following pages for labels 'Visitor' and/or 'Registered user':

• admin/people/roles
• user/1/edit
• admin/config/people/accounts

Ran the tests (5) on local machine, all report 'OK' results.

So for me 'RTBC', but not changing status because of 'Needs product manager review' issue tag.

Changed "Logged-in user" in issue title and summary to 'Registered user'.

I fully agree that the proposed changes to these role labels are improvements to what is currently in place. However, I'm concerned about how this impacts existing documentation/stackexchange/books/et. that reference anonymous/authenticated roles. It's unfortunate this couldn't have landed in 8, where such changes were anticipated by users.

It's possible to argue that the tradeoff is worth it: making Drupal more intuitive overall is worth making some already-confusing documentation outdated. This particular change presents additional risk as the documentation referencing anonymous/authenticated roles is more likely to have security implications. If these labels get changed, I'd at least want it accompanied by changes to D.O. docs, that make it clear that the old/new terms are equally applicable.

Thanks @bnjmnm, yes I agree with you. We definitely need to have updated d.o. documentation in place ready for this change.

Also, thank you @tvb for the comments in #94 - patch #93 was very nearly RTBC but is not quite. I noticed some unanswered questions in this thread so have reviewed the history and compared the patches step by step, starting with patch #63, noted as good by @jhodgdon in #65. We can skip over the few subsequent patch attempts, the next 'good' patch is #75 which was based on #63 but also fixed the tests and raised questions from @jhodgdon. Patch #88 is a valid and straight re-roll of #75. Patch #93 is a re-roll of #88 but also includes one additional change in EntityReferenceSelectionAccessTest.

There are four points that I think need to be addressed:

1. In #76-78 @jhodgdon was concerned about the change to EntityReferenceSelectionAccessTest testUserHandler(). I've tested this locally, both before and after the patch, to see what was going on. The reason that the strings have to be changed is because they are used as a filter on the user label, they are not the machine name. The existing test (before any Anonymous -> Visitor change) would pass with values 'aNON' and 'yMous' or any cased substring of 'anonymous' as these are matched against the user name (label). The purpose of the test would be clearer if the text strings were not the same as the machine name. I checked with 'aNON' and 'yMous' and the tests pass just the same. So some comment along these lines could be added to explain the need to change these strings. We could take the opportunity to change them to 'VIS' and 'iSTor' for example, to make it clear that these are not the machine names.
2. Patch #93 has an additional similar change to that test function, which made me concenred as to why this was not needed before, because the patch was already passing all tests. The reason this did not fail the previous tests is that this group is testing the behaviour of $selection_options['include_anonymous'] = FALSE. The test is infact saying 'match all user names which have the string "Anonymous" but also exclude the anonymous user 0' then we check that nothing is returned. This is only a weak test of the code, because if you enter anything in the string that does not match an existing user name it will return empty anyway, regardless of the 'include_anonymous' = FALSE setting. So the patch passed because 'Anonymous' did not match with any users. It would be a stronger test if we also created a user whose name/label had the word 'anonymous' in it. Then with 'include_anonymous' = FALSE we should still get that one real user returned, but should not get user 0. I have a local version of this test which adds this new user, and it does indeed fail without the new change added in patch #93. I can upload that here if anyone wants to check it, but I guess that improving the strength of the test is not within the scope of this issue.
3. In #70 @jhodgdon says "you do not need to replace the word 'authenticated' (and anonymous) in comments. You only need to replace it in text that a Drupal user would see in the user interface". Patch #93 has three comments where 'anonymous' is changed to 'visitor' so we need to check if these are valid changes.
4. The patch has no comments relating to 'authenticated' or 'registered'. In fact the words 'authenticated' and 'registered' only appear once in the entire patch, as the old and new label values in user.role.authenticated.yml. Does this imply that there is no test coverage at all for the authenticated/registered text? Adding test coverage here is not in scope, but it is worth doing the investigation now, because it does relate to changing the label text.

Hope this helps to summarise the current situation. These are all solvable points and we should be able to make progress, but lets have a disscussion here before any more patches are rolled. Please note the comment by @mradcliffe in #81 that all the novice tasks have been done in this issue, and the 'novice' tag has been removed.

So this is tagged "Needs product manager review" and @jhodgdon asked me to look at this with a Product manager eye. @yoroy already gave his blessings 3 years ago (he was already a product manager then).

Me, as a Drupal old timer, I am probably too biased towards existing terminology. Even while I don't think existing terms are clear, the replacements may not be clear either. As a foreign speaker I am a bit puzzled by "Visitor" meaning "Not logged in". For example, in analytics terms, a visitor is just a person who arrived at the website. Eg. https://blog.alexa.com/full-glossary-web-analytics-terms-know/ says a NEW visitor would be a new person on the site (not authenticated), while a RETURNING visitor would be a person who was here before (could still be not authenticated but could also be authenticated). Other sources of analytics terminology also confirm my understanding as "visitor" being not necessarily unauthenticated: https://www.sitepoint.com/understanding-the-key-terms-in-analytics/

Similarly, to replace "Authenticated user" with "Registered user" (which is not in the current patch but is in the issue summary), I think the term looses a significant distinction. I can be registered but not logged in, in which case I am "Anonymous". For the current "Authenticated user" role, it does not only mean the user is registered but that the user is also currently logged in. To illustrate the difference, a registered user would be able to request a new password when trying to log in (if they forgot it). However, an authenticated user is already logged in. (A user which did not register before would on the other hand not be able to request a new password). So some "Registered users" are in the old terminology "Anonymous" (not currently logged in), while some are "Authenticated user" (currently logged in).

Those are great points -- thanks! It seems like we need to come up with some other names then, because the problems described in the issue summary Problem/Motivation section are still real. Changing the issue title so it is not so specific, and updating the issue summary with these concerns.

So... how to move forward?

"Anonymous user": The issue summary points out that "authenticated users can be anonymous too" (i.e., they might not be using their real names). So we need some other term besides "visitor" that precisely and concisely conveys "Someone who is currently viewing the site without logging in, whether or not they might actually have an account".

"Authenticated user": We still have the problem noted (with evidence) in the issue summary that "lots of people don't understand giving a permission to auth users gives it to every logged in user". So for that, we need some other term that precisely and concisely conveys "Anyone who is currently logged in".

Could we change the role names to "All logged in users" and "Not logged in users"? [adding this proposal to the issue summary]

Thoughts? Any other ideas?

What I like about the "All logged in users" and "Not logged in users" suggestion is they are clearly opposites of each other. Whatever names are ultimately chosen, I hope it's similarly clear they are opposites. Two clear benefits come to mind:

• Its very accurate: being one means not being the other
• Knowing the meaning of one makes it significantly easier to know the meaning of the other.

I am concerned that the plural-ness of "All logged in users" and "Not logged in users" may be confusing since role names tend to be singular. I'd actually be fine with "logged in user" and "not logged in user", despite it sounding a bit more informal than I'm accustomed to in Drupal. Maybe there's an elegant version of those?

That's a good point about singular vs. plural. I'm not sure how to reconcile that with the point in the issue summary, regarding "Authenticated user" current name:
"lots of people don't understand giving a permission to authenticated users gives it to every logged in user."

I think it's also important to realize that these are not really roles in the same sense as other roles, in that you cannot define who is and isn't granted those roles -- they are automatic. All other roles can be granted to particular logged-in users, whereas the authenticated role is automatically granted to all logged-in users, and the anonymous role to people who aren't currently logged in.... So I think I might be OK with having those two roles be plural, since they are somehow different from other roles?

I like the idea of Authenticated user / Unauthenticated user... but it still wouldn't resolve the problem identified in the issue summary that:

It's been shown in UB user testing and anecdotally that lots of people don't understand giving a permission to authenticated users gives it to every logged in user. See #78941: Usability: Auto-check permissions if "authenticated" has them.

Based on your research, I'll update the issue summary to say only that "anonymous" is a Drupalism, not "authenticated". Also to make the point that authenticated/anonymous are not antonyms.

We discussed this issue at today's Usability group meeting #3189076: Drupal Usability Meeting 2021-01-08.

Our conclusions:

a) The names of the two roles should be:
Not authenticated
All authenticated

b) The left column on the permission page should be changed to say:
User permission
(instead of just "Permission")

Here's a screenshot of what (a) and (b) would look like (created by editing the HTML temporarily using Inspect Element in the browser):

c) There are several additional pieces of text on /admin/config/people/accounts that also have the word "anonymous" in them. Those also need to be updated to use the phrase "not logged in". Screenshot of that section of the Account settings page:

As a note, it is confusing what this setting is vs. the anonymous role name that you can edit on the Roles page? I have no idea.

Adding this to the issue summary.

Regarding #104.c:

There are several additional pieces of text on /admin/config/people/accounts that also have the word "anonymous" in them. Those also need to be updated to use the phrase "not logged in". Screenshot of that section of the Account settings page:

I couldn't think of a good example at yesterday's meeting, but here's an example of where I've used this in a custom module:>

We allowed users to submit feedback in a form, this was tied o a custom entity type (let's just call it "feedback"). On the Feedback Entity Form, the user had the option to have the feedback tried to their account, or submit it anonymously. The way we would handle this is that the entity's "author" would be set to UID 0 if the user chose to leave their feedback anonymously. In this way when we viewed the feedback on the backend, those who chose to leave feedback anonymously we would just see the author name as "Anonymous" because that is what the name of User ID 0 is which is defined in this form.

Another example, this time from core, when a user is cancelled, one of the options is to have their content owned by the Anonymous User (User ID 0), that content will then show with the author name "Anonymous" (including any revisions in the Revision UI), or whatever name was given to the Anonymous User on the Account Settings form.

I think in both cases "Anonymous" as the name for the Anonymous User makes sense, that said it might be worth opening a follow-up issue to look at this specific issue, maybe something like: Discuss if it still makes sense for the default name of User 0 to be "Anonymous" (aka the Anonymous User).

Thanks,
-Aaron

Aaaaah, that's an excellent point.

So there are two things that are both called "Anonymous" currently in the Drupal UI:

a) The role name for permissions that apply to people who are not logged in.

b) The somewhat fake user account (whose ID is 0), that is used to identify that content, comments, form submissions, and the like was authored by someone who was not logged in (or in the case mentioned above, who chose not to be identified by their user account). As a note, that is the setting that is shown on the Account settings page.

I think you are saying that the default for (b) should stay as "Anonymous", or at least that this is a separate issue from (a). I think I agree with you, and I don't think we discussed it properly during the meeting, because I for one didn't realize/remember that those two settings were separate.

Updating the issue summary with this point. So, we need to decide what to do...

My suggestion:

1. Leave the default setting for user 0 name as "Anonymous".

2. The admin/config/people/accounts page with this setting currently looks like this:

I think we should change all of the text there:
- Heading: "Unauthenticated user name" instead of "Anonymous user"
- Field label: "User name" instead of "Name"
- Description: "Indicates actions (such as posting comments) by an unauthenticated user" instead of "The name used to indicate anonymous users"

I have not added this to the issue summary yet (don't think it's consensus).