Unify anonymous and registered users

While taking a look at 📌 [P-1] Separate the account information from the user entity. Active @catch found this issue and mentioned they both could be moved to the ideas queue.

@catch should receive credit for finding this though.

This is a really good idea! I have definitely wanted something like this in the past and so can really appreciate the use-cases mentioned in the summary.

If Drupal is to become a first-class Digital Experience Platform, we need the data structures to support that. Email subscribers to a newsletter are also a good example here, an email subscriber should be able to update their preferences, but they shouldn't need to have a full account just to do that or to subscribe in the first place.

Some thoughts on this.

The User entity in Drupal has a very specific meaning. It is not a Person, it is a User, meaning somebody that uses the system. Otherwise, it is not a user, it is something else.

Regarding some of the examples mentioned:

- Email subscribers, that would be a separate Email Subscriber entity provided by the module that provides the newsletter functionality. If the subscriber does not need to log in to update their preferences, then, there is no reason to have a User for the subscriber; the Email Subscriber entity will be updatable by an anonymous user according to whatever criteria anyway.

- CRM contact, again, that's not a User, a custom or contrib module should provide a Contact entity with all the required features, there is no reason to make a Contact be a User if they don't log into the system.

- If an entity needs extra data that should not be stored on the main entity, then the profile module or alternative should allow creating a profile or data record and attach it to other entities. That is, the solution is not to make the Contact entity a User, the solution is to attach another data record to the Contact.

- About anonymous users commenting, I'm not sure why there is a fake session created. Without knowing the reason, it seems better to me that the comment entity just holds the data for the comment and they are rendered as fields. If somebody would comment why a session is needed, that could help understand the case.

All that said, it is possible to stretch the meaning of the User entity a bit. For example, an anonymous user that comments also uses the system even without logging in. A user that subscribes to the emails via the website, and then visits the website to unsubscriber, also uses the system.

The argument of being able to use modules/features that are tailored to users is a strong argument as well. I disagree with it as an architect; for example, for integrating CRM Contacts with Commerce (as per the examples listed in this issue's description), the correct solution would be to improve the Commerce system to not require a User entity. Or, as mentioned above, to improve the Profile module to be able to attach profiles to any entity. However, let's be practical, it would be very useful and opening up many possibilities if we could just use those modules without having to rewrite them - who will do that?

In that case, I think that the solution would be to make the User entity bundleable. Then the default behavior will be kept exactly the same as now where the default bundle will be for Authenticated users. Then modules could add a Contact bundle, an Anonymous User bundle etc.

Modules should be very careful though if they automatically generate users for anonymous visitors, and be sure to take into account the following:

- Purge users that are not required any longer, otherwise the database can end up with an extremely large number of unnecessary entities - depending on the use case. Imagine creating a user for each session, even if the actual visitor is the same physical person on the same physical device.
- Be careful with GDPR or other privacy related requirements.
- Be cautious of potential performance impact.

In summary, I think that the best is to add support for bundles on the User entity in Drupal core without changing anything there. And then have custom/contrib to take advantage of them as needed.

In summary, I think that the best is to add support for bundles on the User entity in Drupal core without changing anything else there. And then have custom/contrib to take advantage of them as needed.

Adding bundles to the user entity could be a really good way of enabling some of these usecases. I had a use case a while back for user bundles, where I had two types of users who had very different business requirements and it would be enough to justify two different "user types".

The User Bundle contrib module → shows that adding bundles to user is definitely feasible.

Having said that, from a product perspective, does it really make sense to introduce the concept of "user types", does that just complicate things for site builders when, arguably, most sites won't have a need for that feature. Maybe it is better to just leave that to the contrib project.

The proposal in this issue though I think is still valid on its own, whether we add user bundles or not. Perhaps a better justification would be, making it easier for themes, like Olivero and Claro, to allow the user to customize some aspects of the theme (for example turn on dark mode), in a way which saves those preferences to the session, so that it still works for users who are logged out. That is a legitimate potential use case that we could have in Core, whereas the CRM or email subscriber use cases are not strictly Core use cases.

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

Changing to the standard issue template → would also help other contributors.