user.html.twig documentation refers to a nonexistent 'account' variable

Hi,

Please test the patch attached, this will fix it.

I'd suggest a good next step here might be to figure out when this was lost, assuming it was there before :)

This is slightly related to #2385243: Make core user fields available for twig templates, but mostly I think what we should do in this issue is update the documentation to use content.field_example rather than account.field_example (and so on).

Setting to active to reflect that we need a new patch/new approach.

I changed the documentation to use content as an example instead of account. However, I think some other changes might be necessary:
There is a user variable available with a variety of account related fields. Perhaps this information is what "account.field_example" was originally referring to?
There are no language-specific variables (eg. "content.member_for" exists, but not "content.member_for.en") -- unless I'm missing something.

+++ b/core/modules/user/templates/user.html.twig
@@ -10,11 +10,11 @@
+ *   variable is defined; e.g., content has a variable

Please change documentation from variable is defined; e.g., content has a variable to variable is defined; e.g., content.field_example has a variable.

Thanks for the patch!

Hm....

+++ b/core/modules/user/templates/user.html.twig
@@ -10,11 +10,11 @@
  * - Field variables: For each field attached to the user a corresponding
- *   variable is defined; e.g., account.field_example has a variable
+ *   variable is defined; e.g., content.field_example has a variable
  *   'field_example' defined. When needing to access a field's raw values,
  *   developers/themers are strongly encouraged to use these variables.

I think this is still confusing. content.field_example is not a variable in itself -- it's a component of the content variable.

And it seems to be confusing cause (the site has a field called 'field_example' defined for user accounts) with effect (this Twig template's content variable has a component called field_example on it).

So... Can we make another attempt to rewrite this so it is clearer please?

Oops, of course this issue is related to itself, don't need metadata for that ;)

Rerolled the patch.

Downloaded and applied the patch with no issues. Not sure if it's necessary for documentation, but I also attached a screenshot. Looks good to me.

My feedback on #14 was not addressed. Please take a look -- thanks!

I changed it to no longer say that 'field_example' has a variable also called 'field_example' defined.

Thanks! This is almost there... I still think it is a bit unclear. With the latest patch, it says:

For each field attached to the user a corresponding variable is defined; e.g., user has a variable 'field_example' defined.

How about changing this to:

For each field attached to the user entity, a corresponding variable is available. For example, if there is a field called 'field_example', this template will have a field_example variable available.

Or something like that?

How are these changes?

Thanks for the new patch! Not sure it's correct though?

I think I'd better leave this for someone else to review, because I am really not sure what is in the template... but here are my thoughts (which might be wrong except the first point):

1. +++ b/core/modules/user/templates/user.html.twig
   @@ -9,13 +9,13 @@
   + *   variable is available. For example, if a user has a field 'field_example', ¶
   

   There's an extra space at the end of this line.

2. +++ b/core/modules/user/templates/user.html.twig
   @@ -9,13 +9,13 @@
   + *   this template will have a user.field_example variable available.
   

   Um, is the variable in the template really called "user.field_example"? I thought it was just "field_example"?

3. +++ b/core/modules/user/templates/user.html.twig
   @@ -9,13 +9,13 @@
   + *   strongly encouraged to use these variables. Otherwise they will have to
   + *   explicitly specify the desired field language, e.g. user.field_example.en,
   + *   thus overriding any language negotiation rule that was previously applied.
   

   So this is saying that if you use user.field_example you need to specify the language... so I think the point of this documentation is to say that there are special variables created that match the names of the fields (without user. prepended). Right?

I missed this when I commented here earlier, but very importantly these "field variables" on the top level no longer exist, so the documentation needs a bigger overhaul (or maybe even just removal).

See template_preprocess_user(). Mainly 'user' and 'content' which contains the fields. Some of the 'properties' can be accessed via user, not sure if the same language caveats apply to those. Potentially the docs could be moved to the 'user' variable and adapted to make sense there.

For debugging I recommend installing Kint from https://www.drupal.org/project/devel and adding {{ kint() }} to the template whose variables you're trying to figure out.

Edit: Forgot to mention, for that to work uncomment the line about Twig debug in sites/default/services.yml and clear caches (or drush cr) :)

In that case I think there are no "field variables" and we should just remove that section of the docs?

I would be fine with that myself.

What I think I see here is that all of the user's fields are actually available in content or content.member_for but not in top-level variables like member_for or field_example.

The user variable also appears to be unavailable since its members are all protected.

So I would change the documentation to remove mention of variables user and 'Field Variables' and expand the description of the content variable to say that a user's fields are available there.

There are also variables like logged_in and is_admin. Should we mention them in the documentation?

user was specifically added in #2385243: Make core user fields available for twig templates. Its properties may be protected but getter methods can be used to get at fields that aren't in content - see Available methods.

logged_in and is_admin are generic variables available to all templates so don't need to be documented, see _template_preprocess_default_variables().

So what I would suggest to move forward here is merging some of the docs from 'Field variables' to make the 'content' variable documentation better - like @tbradbury mentioned:

…expand the description of the content variable to say that a user's fields are available there.

• Removed entire "Field Variables" section.
• Provided additional example in documentation of 'content' variable.
• Updated documentation in 3/3 instances of user.html.twig in core.

+++ b/core/modules/user/templates/user.html.twig
@@ -8,20 +8,12 @@
- *
- * @ingroup themeable

This needs to stay, but only in the default user.html.twig.

Otherwise this looks quite reasonable to me, thanks @tbradbury!

Ah, thanks, didn't notice I killed that.

Works for me, thanks!

+++ b/core/modules/user/templates/user.html.twig
@@ -8,14 +8,8 @@
- * - Field variables: For each field attached to the user a corresponding
- *   variable is defined; e.g., account.field_example has a variable
- *   'field_example' defined. When needing to access a field's raw values,
- *   developers/themers are strongly encouraged to use these variables.
- *   Otherwise they will have to explicitly specify the desired field language,
- *   e.g. account.field_example.en, thus overriding any language negotiation
- *   rule that was previously applied.

This documentation about language seems extremely relevant. Did anyone test a multilingual install. Also entity field access has a lot of magic so just inspecting the content variable might not be enough to prove content.user_picture.en or (for example) content.user_picture.fr does not work.

I did some testing after installing multilingual modules.

1. Enabled modules Language, Interface Translation, Content Translation, and Configuration Translation.
2. Added language French and set French as default language.
3. Verified that French translations are used on /user/1 (eg: in {{ content.member_for }})
4. Checked output of {{ content.member_for.en }} and {{ content.member_for.fr }}.
   • Both have null output.

+++ b/core/modules/user/templates/user.html.twig
@@ -8,14 +8,8 @@
- * - Field variables: For each field attached to the user a corresponding
- *   variable is defined; e.g., account.field_example has a variable
- *   'field_example' defined. When needing to access a field's raw values,

This is still the case, but it's now content.field_example instead of field_example. I think a more appropriate test would be user.field_example.en, user being the closest analog to the old account variable.

Thanks @tbradbury!

This is still the case, but it's now content.field_example instead of field_example.

I think the patch still explains that a user's fields are available as content.field_example. It now says:

- content: A list of content items. Use 'content' to print all content, or print a subset such as 'content.field_example'. Fields attached to a user such as 'user_picture' are available as 'content.user_picture'.

I think a more appropriate test would be user.field_example.en, user being the closest analog to the old account variable.

I tested user.member_for and user.user_picture, plus both with .en and .fr. None of them had any output. From what I can tell, you can't actually access anything in user except with its methods - user.getEmail() and the like.

Okay, then it sounds like we're covered. In general I think the documentation around the language variables was "don't use these" anyway. Thanks @tbradbury!

Docs are not frozen in beta. Committed d416fab and pushed to 8.0.x. Thanks!

I confirmed with @berdir that translated versions on fields can no longer be accessed this way.