Improve and clarify User|Profile help pages and UIs to clarify when fields on users vs. profiles are appropriate

Created on 17 February 2013, about 12 years ago
Updated 31 January 2024, about 1 year ago

Follow-up to: ✨ Move simplified Profile module into core Closed: won't fix

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

  1. This is a pure educational issue - as soon as you've understood the difference and concepts, you know it.
  2. 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.

πŸ“Œ Task
Status

Closed: won't fix

Version

11.0 πŸ”₯

Component
ProfileΒ  β†’

Last updated about 1 year ago

No maintainer
Created by

πŸ‡©πŸ‡ͺGermany sun Karlsruhe

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

Production build 0.71.5 2024