Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Follow-up to: #1668292: Move simplified Profile module into core
Problem
- For non-developers, it is not clear when it is appropriate to use fields on user accounts directly vs. fields on a profile entity.
Details
-
Additional fields on the User entity itself...
- imply direct loading of all field data for every loaded user account whenever it is loaded, which is a memory + performance disaster.
- may be grouped into categories via facilities like Field group module, but the more fields you have there the slower gets your site, and they're also not suitable for use-cases; e.g., like multiple addresses in Commerce.
-
Fields on the User entity itself are appropriate for data that is needed on >80% of all pages and interactions; e.g.:
- User picture (avatar)
- Signature (forum comments)
- Realname / First + last name (if constantly output instead of actual username)
This data is available at any time. Whenever and wherever a user account is loaded, this field data is loaded and prepared, too.
Note: For the majority of possible Drupal use-cases, this list is actually complete. It essentially maps to everything you possibly might want to show in the "Compact" display/view mode of User entities (which exists in HEAD already and is used for rendering the user picture in comments — you can configure which fields appear in there).
-
Profiles represent categorized sets of user profile data. They're appropriate for data that is needed in specific cases only - or which is perhaps even recorded for posterity only; e.g.:
- Personal information & biographic data (only shown and needed when actually visiting a user's profile page)
- Site-specific policies and opt-in flags; e.g., privacy policies, T&Cs, newsletters, notification settings, etc. (all of these are rarely accessed and needed)
- Address and/or billing information (required for certain site operations/actions only)
- User role-specific enhancements ("Premium" profile data, etc)
This data is only available after explicitly loading it. Like all content and nodes you've authored, they're not immediately and always available just because your user account is loaded. However, as with any other content, you can easily generate listings and aggregates of the profile/category-specific data via Views.
- For developers, the fundamental difference between these two possibilities is pretty clear. But for "end-users" and less technically versed site-builders, the underlying architecture, performance impact, and question of choosing one over the other is most likely not really clear.
Proposed solution
- This is a pure educational issue - as soon as you've understood the difference and concepts, you know it.
-
Adjust the administration pages of both User and Profile module to help users to choose the appropriate tool for the field they want to add.
Don't bury it into the help pages, since almost no one reads those.
Comments
Comment #1
mbrett5062 CreditAttribution: mbrett5062 commentedThe issue this is a follow-up to has been bumped to 8.1.x-dev, should this not also be bumped?
Comment #2
mgiffordMakes sense.
Comment #18
smustgrave CreditAttribution: smustgrave at Mobomo commentedWas determined to keep profile in contrib in #1668292: Move simplified Profile module into core