Accessing the original entity in field templates is hard

This would be nice.

A little consistency in the variables available goes a very long way for us. This is especially true because debugging in templates right now is a nightmare, so every little improvement helps.

Yeah I think that help ease the pain for themers.

Here's a patch.

This seems to be a nice idea to give access to the template for other fields.

Let's add tests for this then.

Here is a more complete patch which alter some field templates too.

How can I add a test for this patch now? It will be my first test so...help is welcome!

Don't forget to mark the issue as «needs review» to process tests.

On my local 8.3.x, I have applied the patch in #9.

In a field.html.twig, I included 'dump(entity)'.

Output of the object was printed to the screen, when viewing a node with fields.

I conclude this is working correctly.

We still should have a test for this.

How can I test that a variable is available in a template?

@kikoalonsob, you can create or mock an node and print it's label with {{ entity.label }} in a field template as a possible test and assert the node title is displayed in that field. There are a bunch of examples of this in the existing tests to copy from.

add tag DevDaysSeville

With a little help of @webflo : implemented a test for this function

Still applies, seems reasonable to want access to the entity, has tests. I'd RTBC it but there are a few comments needed on the other field templates.

To help find them use these:

find . -name field--*.html.twig
find . -name field.html.twig

I used the find commands and checked the field templates.

Only 2 have no comments:

./core/modules/big_pipe/tests/themes/big_pipe_test_theme/templates/field--comment.html.twig -- Test only
./core/themes/classy/templates/field/field--text.html.twig -- extends field.html.twig

Test does not need a comment.
The other templates extends the original field.html.twig, so also no comment is needed.

The others are ok:

./core/modules/comment/templates/field--comment.html.twig -- ok
./core/modules/node/templates/field--node--created.html.twig -- ok
./core/modules/node/templates/field--node--title.html.twig -- ok
./core/modules/node/templates/field--node--uid.html.twig -- ok
./core/themes/bartik/templates/field--node--field-tags.html.twig -- ok
./core/themes/classy/templates/field/field--comment.html.twig -- ok
./core/themes/classy/templates/field/field--node--created.html.twig -- ok
./core/themes/classy/templates/field/field--node--title.html.twig -- ok
./core/themes/classy/templates/field/field--node--uid.html.twig -- ok
./core/themes/classy/templates/field/field--text-long.html.twig -- extends field--text.html.twig
./core/themes/classy/templates/field/field--text-with-summary.html.twig -- extends field--text.html.twig 
./core/themes/stable/templates/field/field--comment.html.twig -- ok
./core/themes/stable/templates/field/field--node--created.html.twig -- ok
./core/themes/stable/templates/field/field--node--title.html.twig -- ok
./core/themes/stable/templates/field/field--node--uid.html.twig -- ok

./core/modules/system/templates/field.html.twig -- ok
./core/modules/system/tests/themes/test_theme/templates/field.html.twig  -- ok
./core/themes/classy/templates/field/field.html.twig -- ok
./core/themes/stable/templates/field/field.html.twig -- ok 

There are no additional comments necessary.
I talked about it with joelpittet, he agreed to RTBC is. So I put it do RTBC.

Thanks for double checking field--text.html.twig, I didn't realize they were extending.

I see why it can be valuable in some cases. But at the same time, this moves us further away from having simple templates with just the data it needs injected. This patch explicitly adds the ability to easily get data not from the current level, but from the parent level.

If we decide we want this, ok, but we should be conscious about that.

I agree with you. In the current state of things, this probably makes sense. I just want us to realize there are indirect consequences too, that is all.

Tagging for a front-end committer to review.

Hmm. I kind of feel like accessing the original entity in field templates should be hard, to avoid having business logic in templates?

Edit: I guess this is what #31 is getting at also.

But I'm kind of -1 to this change also.

It seems like these discussion always come back to ease of access to context, which is very important in practice, but is sometimes discounted or overlooked in these discussions. I think the business logic argument is misapplied here. There is *always* going to be a need to derive context and act/theme/style accordingly. If we want to remove the process layer, which is a stated goal in #2702061: Unify & simplify render & theme system: component-based rendering (enables pattern library, style guides, interface previews, client-side re-rendering), I think we need to accept that context is needed, and make it a priority when considering changes.

Here are some real examples of where accessing the parent/child entity has been needed (not all are for fields but the general idea is the same):

1. Nested Entities Galore

   We're dealing with more entity references than ever before, which makes theming harder. What you want to change may require going through 4-6 layers of templates. This is why people are fond of modules like Twig Field Value. Most people don't want to go through all that just to print a field value, and you can't really blame them. Kint and friends are not helpful here, so unless you are very patient and willing to sit there taking shots in the dark for hours (like me), you need to know the magic methods to get anything useful, in a debugger. Most people are sane, and just bypass this all completely, because it's VERY time consuming. And if you question the 4-6 levels of templates, let me give an example of one I'm working on as we speak:

   1. node.html.twig
   2. field--node--field-hero.html.twig or field--entity-reference-revisions.html.twig
   3. 1. paragraph--hero.html.twig
      2. field--paragraph--field-video--hero.html.twig
      3. media--youtube.html.twig*
      4. field--media--field-video-url--youtube.html.twig*
      5. container--video-embed-iframe--youtube.html.twig**
      6. video-embed-iframe--youtube.html.twig*

      *These suggestions need to be customized, they're not specific enough. The Hero context needs to be explicit. Why? Because in the Hero context the video autoplays like a background image via the YouTube API, and in other places, it just needs to be a standard video embed.

      **This suggestion has already been customized. However, no other information is available to the the container, so I cannot complete this task without devoting more trial and error time to it, or without backend help. Sigh.

   4. Context of Parent entity, or Field value on Parent Entity

      In the same Hero component (paragraph entity), the design calls for using the parent node title in some cases (specifically, the articles vs landing pages). Paragraphs provides access to the parent entity, so the code was simply:

      {% set parent = paragraph.getParentEntity %}
      {{ parent.label }}
      

   5. Different Component Templates/Attributes/etc based on Parent/Child

      Back to the hero again, some have video media entities attached, others have images. In this case, you nay need to access the parent and the child entities to achieve designs. For example, if the child entity is a video media entity it might need different classes, and/or component template than an image.

   6. Wrapping a Field in a Link to the Parent

      Sometimes you just need to wrap an entity reference field in a link to parent entity, INSIDE the field wrapper, not outside. You might say this is the job for a formatter, but I disagree. Formatters only further increase the business logic in templates, because as the template author you've no control over what data structure might be sent to the template, due to options in the UI. They also come with complex caching challenges. A great example of potentially different data structures is a date field. It can be a timestamp, themed via #time, or just #markup. Fatal errors for trying to manipulate what is expected to be a timestamp, but isn't because someone changed the formatter is always fun.

   7. Providing a proper HTML structure

      Given a field_heading on a Paragraph entity, need to find the depth to give an accurate HTML/outline heading level, e.g.

      1. Parent is a node, the tag should probably be an H2.
      2. Parent is a paragraph, tag should probably be an H3.
      3. Parent is another field, the tag should probably be an H4, etc

   Bingo!

   I think this all comes down to the fact that entity/field templates aren't the actual right level of rendering. You want to build components to render stuff and just somehow pass along data to your domain specific component templates. For me at least, if field templates are the place you need to call out to those component templates, using the entity might be needed in that place.

   Exactly. I think most people would rather not get down to field templates for theming. We have a responsibility as coders to at least attempt to make our code as simple and readable as possible, but spreading everything out across soooo many templates, is counter to that goal. However, it's not escapable, so for me, it really depends on what kind of field it is. When I can, I do try to do as much as possibly globally for fields, e.g. field--field-type.html.twig. That way when I'm working in a parent entity, I can just print, or send it off to a component template as is, because that's easy to read/maintain, etc. However, that doesn't always make sense, and when I do need to get into a field template, I'd agree that accessing parent entity needs to be possible/easy. My point in mentioning this is the Context drives all of this, and context is often really hard. We should try to make it easier instead of harder. Saying this isn't needed to someone working with Drupal templates is sort of like saying you should not be able to have different labels and field settings for a given field that is shared across bundles of the same entity to a backend developer.

   ---

   This ended up being a much longer reply than I anticipated, and I assure you the tone of it is not snarky or anything. I'm just trying to provide some insight into the day-to-day challenges in hopes that we can all just accept that we need context AND business logic, and factor that into the solutions being developed.

   And Ultimately, I think the Paragraphs solution, of being able to use getParentEntity() is the best one, so if we can do something like that, it'd probably be better.

Thanks @Jacine, all that context (pun!) is really helpful for understanding this issue.

Sure! I'm really glad it's helpful... :o)

Stopping in to weigh in as one of the frontend framework managers:

IMO lack of context is (still) one of the biggest pain points in Drupal theming and something that people run into almost daily. I'm in favour of this change. At a glance, the patch looks reasonable and straightforward but I can't review or test it thoroughly at the moment.

Special thanks to @Jacine for the write up in #37.

Sidenote: I can't find the issue, but at one point during the D8 cycle theme system maintainers had discussed adding a separate $context alongside $variables so that stuff like this could be referenced in preprocess/templates to know where the hell you are in the nesting dolls.

@Cottser, @effulgentsia, and I discussed this issue today and came up with a couple recommendations:

1. @Cottser previously proposed adding #2511548: Add a "context" array variable to all theme hooks and "#context" array property to all elements to provide optional contextual data. That's still open, but cites a past issue #2495419: Move the 'search-results' class from the render array and into a Classy template where it was added for providing metadata to a template for search. So let's do something like that here as well, by adding the entity to a context array in the variables. Using that pattern will help themers distinguish between information that's part of the current template, and information about what context the template is in to theme it based on that context.
2. core/modules/node/templates/node.html.twig has some detailed documentation explaining what is and isn't available to do with the node entity there. We should provide similar docs in the field template about the field entity.
3. We should probably also expand the tests that, to assert that you can't do the forbidden code-execution-type things that we indicate we restrict in the node template.

The patch is failing on a test that was broken in HEAD recently; it looks like it's not getting retested. But since we're updating the patch anyway that is fine.

Thanks everyone for working on this, and for explaining why it's needed.

Adding credit.

Other reviewer credits.

{{ element['#object'].getCreatedTime | date('F j, Y') }}
Worked for me.