|without Twig filter doesn't remove fields from the entity output

I can confirm this behaviour, but I am also unsure if this is related to ECK and have not been able to track down it's cause yet. Any help is greatly appreciated.

Trying to figure out what's going on in order to fix it, but I did find a workaround:

Digging down one more layer to #entity, 'without' works. So the workaround is {{ entity.entity|without('field_name') }}.

I'm currently working w/ @joelpittet at MidCamp trying to figure out how this workaround actually manages to work. But in the meantime...

Planning to work on this today at the MidCamp sprint.

Ignore #4, but the attached patch should fix things. Basically, I went through and tried to get the entity rendering to be more like how rendering nodes work. Also added a few default classes for the template.

+++ b/eck.module
@@ -233,16 +236,11 @@ function eck_theme() {
-  $sanitized_view_mode = strtr($variables['entity']['#view_mode'], '.', '_');
...
-  $suggestions[] = 'eck_entity__' . $sanitized_view_mode;
   $suggestions[] = 'eck_entity__' . $entity->getEntityTypeId();
-  $suggestions[] = 'eck_entity__' . $entity->getEntityTypeId() . '__' . $sanitized_view_mode;
   $suggestions[] = 'eck_entity__' . $entity->getEntityTypeId() . '__' . $entity->bundle();
-  $suggestions[] = 'eck_entity__' . $entity->getEntityTypeId() . '__' . $entity->bundle() . '__' . $sanitized_view_mode;
   $suggestions[] = 'eck_entity__' . $entity->id();
-  $suggestions[] = 'eck_entity__' . $entity->id() . '__' . $sanitized_view_mode;

This removes template suggestion granularity and does not help fix the issue. So these lines should be reverted.

Besides that, the patch looks like a clean solution to the problem. I would like to see the tests passing again though ;)

Thanks for your efforts on this!

Looking into the tests the morning. :)

The reason I removed the suggestions involving view mode is because ECK entities don't have view mode options -- but doesn't hurt to leave them in I guess!

Let's try this. We can't get rid of the default $build['#{entity_type}'], because that's what the Entity system wants to use for some of its internal tests, leading to the failures we saw. With some work, we could probably override that if desired (I started down that path but don't know the routing system well enough yet).

The preprocessing of Element::children into the $content variable is possibly the only thing that's needed to fix, but I think the change of entity to elements and eck_entity helps to keep things clear.

1. +++ b/eck.module
   @@ -255,3 +257,19 @@ function eck_entity_bundle_field_info_alter(&$fields, EntityTypeInterface $entit
   +  $variables['type'] = $variables['eck_entity']->getEntityTypeId();
   

   I think entity_type is a more descriptive key.

2. +++ b/eck.module
   @@ -255,3 +257,19 @@ function eck_entity_bundle_field_info_alter(&$fields, EntityTypeInterface $entit
   +  // Helpful $content variable for templates.
   

   This comment seems incorrect to me. It is not a helpful variable since it is the main variable being printed.

3. +++ b/eck.module
   @@ -255,3 +257,19 @@ function eck_entity_bundle_field_info_alter(&$fields, EntityTypeInterface $entit
   +  $variables += array('content' => array());
   

   Please use the shorthand notation for arrays as per Drupal's coding standards.

4. +++ b/templates/eck-entity.html.twig
   @@ -1,3 +1,43 @@
   + * - attributes: HTML attributes for the containing element.
   + *   The attributes.class element may contain one or more of the following
   + *   classes:
   + *   - eck-entity: The current template type (also known as a "theming hook").
   + *   - eck-entity--type-[type]: The type of the ECK entity. For example, if the
   + *     entity is named "My Widget" it would result in "node--type-my-widget".
   + *     Note that the machine name will often be in a short form of the human
   + *     readable label.
   + *   - eck-entity--bundle-[bundle]: The bundle of the ECK entity. For example,
   + *     if the bundle is named "Banner" it would result in
   + *     "eck-entity--bundle-banner". Note that the machine name will often be in
   + *     a short form of the human readable label.
   

   These classes are not set during preprocessing and therefor should not be mentioned in the description of available variables.

5. +++ b/templates/eck-entity.html.twig
   @@ -1,3 +1,43 @@
   + *     entity is named "My Widget" it would result in "node--type-my-widget".
   

   Still mentions 'node'

6. +++ b/templates/eck-entity.html.twig
   @@ -1,3 +1,43 @@
   +{%
   +  set classes = [
   +    'eck-entity',
   +    'eck-entity--type-' ~ type|clean_class,
   +    'eck-entity--bundle-' ~ bundle|clean_class,
   +  ]
   +%}
   

   Let's not set all these classes by default.

It would also be nice if the functioning of the |without could be proved with a tests.

Thanks for the feedback!

The attached patch addresses all points in #12. Re 12.6, I left one class in. I'm torn on that because from one perspective, if a contrib module isn't adding any styles, then it doesn't need classes in its templates. On the other hand, Classy-based themers have opted into informative classes and might be approaching theming from a CSS-first perspective (which is where I started in theming).

Looking into adding the tests now, setting NR for testbot.

Created #2697093: Add tests for eck-entity.html.twig specifically for the tests.

1. +++ b/eck.module
   @@ -207,8 +208,9 @@ function eck_menu_local_actions_alter(&$local_actions) {
   +    $build['#eck_entity'] = $entity;
   

   I am not sure why you have renamed entity to eck_entity.

2. +++ b/templates/eck-entity.html.twig
   @@ -1,3 +1,30 @@
   +  {{ content }}
   

   I have looked into node.html.twig as an example which doesn't have any classes so not sure if you need to have one here.

15.1 - #entity is extremely generic, and I found it confusing while working on this issue. Typically, the build/render arrays for entities name this key as the entity type -- i.e. #node and #user. With the code in eck_entity_view_alter(), we're adding a new copy of the entity under #eck_entity, so that our template preprocessing, altering, etc. will always have a standard key to work with (since entity types are created dynamically, we can't use the entity key for ECK entities). It made sense to me to namespace #entity to clarify why it's being included at all.

15.2 - I mentioned in #13 in response to 12.6, I'm a fan of providing "wayfinding" classes for easier out-of-the-box styling, but I recognize that it's a personal preference. I'm ok with taking it out if the maintainer agrees.

Committed and pushed to 8.x-1.x. Thanks!

I still experience this issue in 1.0-alpha3. What happens is that the field of a bundle is (probably first removed and) added as the last field when using the filter, instead of not showing it at all.

> I still experience this issue in 1.0-alpha3.

This fix did not make it into alpha 3.