The documentation in the user.html.twig template describes the use of a account variable. However {{ dump(account) }} returns no data. This is either a documentation or a code fault.

Current documentation:

 * Available variables:
 * - content: A list of content items. Use 'content' to print all content, or
 *   print a subset such as 'content.field_example'.
 * - 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.
 * - attributes: HTML attributes for the container element.

Comments

Sagar Ramgade’s picture

Status: Active » Needs review
FileSize
479 bytes
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 87,112 pass(es), 38 fail(s), and 1,738 exception(s). View

Hi,

Please test the patch attached, this will fix it.

Status: Needs review » Needs work
Sutharsan’s picture

If it was that easy... There is a $variables['user'], I did discover that and went down the rabbit hole with it, but no luck. Got confused (as in D7) by the seemingly inconsistent naming of 'account' and 'user' throughout core. The content entity methods like $node->field_foo->value don't apply to user. {{ user.field_foo }} does not work now.

Sutharsan’s picture

If the profile data is not available, I doubt whether we should load it in the preprocess since it is not used in the template at all. We could add this, but it would be a waste of resources: $variables['account'] = User::load($variables['user']->id());. If so, we are better off by removing the account info from the documentation.

Cottser’s picture

Issue tags: +Twig
Cottser’s picture

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

Cottser’s picture

Title: Account variable not available in user.html.twig » user.html.twig documentation refers to a nonexistent 'account' variable
Component: theme system » documentation
Status: Needs work » Active
Issue tags: +Novice, +Quick fix

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.

Cottser’s picture

tbradbury’s picture

Issue summary: View changes
FileSize
1.05 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,685 pass(es). View

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.

tbradbury’s picture

Status: Active » Needs review
leeotzu’s picture

Status: Needs review » Needs work
+++ 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.

leeotzu’s picture

Issue tags: +SrijanSprintNight
yogen.prasad’s picture

Status: Needs work » Needs review
FileSize
1.06 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 95,742 pass(es). View
jhodgdon’s picture

Status: Needs review » Needs work

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?

Cottser’s picture

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

neetu morwani’s picture

Assigned: Unassigned » neetu morwani
neetu morwani’s picture

Status: Needs work » Needs review
FileSize
1.16 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Failed to run tests: failed during invocation of run-tests.sh --clean. View
neetu morwani’s picture

Assigned: neetu morwani » Unassigned

Status: Needs review » Needs work
Nitesh Sethia’s picture

Status: Needs work » Needs review
FileSize
1.05 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch user_html_twig-2428861-20.patch. Unable to apply patch. See the log in the details link for more information. View

Status: Needs review » Needs work

The last submitted patch, 20: user_html_twig-2428861-20.patch, failed testing.

deepakaryan1988’s picture

FileSize
1.09 KB
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Failed to run tests: failed during invocation of run-tests.sh --clean. View
deepakaryan1988’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
Nitesh Sethia’s picture

Status: Needs work » Needs review
FileSize
1.09 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 96,935 pass(es). View

Rerolled the patch.

Daniel_Rose’s picture

Issue summary: View changes
Status: Needs review » Reviewed & tested by the community
FileSize
246.87 KB

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.

jhodgdon’s picture

Status: Reviewed & tested by the community » Needs work

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

tbradbury’s picture

Status: Needs work » Needs review
FileSize
1.33 KB
1.33 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 96,924 pass(es). View

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

Status: Needs review » Needs work

The last submitted patch, 28: user_html_twig-2428861-28.patch, failed testing.

Status: Needs work » Needs review
jhodgdon’s picture

Status: Needs review » Needs work

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?

tbradbury’s picture

Assigned: Unassigned » tbradbury
Status: Needs work » Needs review
FileSize
1 KB
1.51 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 96,984 pass(es). View

How are these changes?

jhodgdon’s picture

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?

Cottser’s picture

Status: Needs review » Needs work

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) :)

jhodgdon’s picture

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

Cottser’s picture

I would be fine with that myself.

tbradbury’s picture

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?

Cottser’s picture

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.

tbradbury’s picture

Status: Needs work » Needs review
FileSize
3.62 KB
3.56 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,033 pass(es). View
  • 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.
Cottser’s picture

Status: Needs review » Needs work
+++ 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!

tbradbury’s picture

Status: Needs work » Needs review
FileSize
384 bytes
3.47 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 97,491 pass(es). View

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

Cottser’s picture

Status: Needs review » Reviewed & tested by the community

Works for me, thanks!

alexpott’s picture

Status: Reviewed & tested by the community » Needs work
+++ 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.

tbradbury’s picture

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.
Cottser’s picture

+++ 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!

tbradbury’s picture

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.

Cottser’s picture

Status: Needs work » Reviewed & tested by the community

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!

alexpott’s picture

Status: Reviewed & tested by the community » Fixed

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.

  • alexpott committed d416fab on 8.0.x
    Issue #2428861 by tbradbury, Nitesh Sethia, neetu morwani,...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.