Prevent disabled fields from being rendered (performance)

I don't necessarily agree that this is a good idea. For a user not using DS, your assumption that a newly created EVA view might only be wanted in a particular view mode doesn't really stand. My feeling is that most users want to configure their new view and then have it show up immediately. Factor in the caching issues that we've been seeing and people might get quite frustrated trying to get their new EVA view to actually show up.

Is there some way we can avoid the problems with infinie loops without setting the field to be disabled by default? Or is it up to site builders to avoid infinite loops?

Again, I'm not huge on the idea of adding another step to making an EVA view actually show up. If someone has a solution for avoiding infinite loops that doesn't involve hiding a new EVA view by default, please reopen this issue.

How about making EVA field visible only at default view mode initially? I think this is how other fields behave. Also if I have 10 view modes, adding a new EVA field means I had to turn it off in 9 of them, it's a lot of unnecessary work.

Fit introduction to new issue title.

We absolutely want to do this! But we can't yet.
#1256368: Add 'visible' key to hook_field_extra_fields() is the core issue that blocks this.

Postponing for now.

For me, this issue manifested itself by preventing pagers on my search pages from showing. Apparently Drupal treats a pager as a global variable, which were reset by the views attached to some of the entities that were appearing in search results. Global variables and re-entrant rendering don't get along. Just dropping a note here to improve the search-ability of this issue. Following the suggestions in #1296596: Extra fields reported "visible" at first, while placed in "disabled" region resolves this issue, although it's an annoying step.

Updating issue title and adjusting prio.

This actually is a core issue: #1256368: Add 'visible' key to hook_field_extra_fields()
More info in the DS issue: #1296596: Extra fields reported "visible" at first, while placed in "disabled" region

Workarounds:
* Manually enable and then disable a field
* Patch from the core issue: #1256368: Add 'visible' key to hook_field_extra_fields()
* Workaround from the core issue: #1256368-105: Add 'visible' key to hook_field_extra_fields()

Postponing to leave it open until the core issue is fixed.

Just had #2289601: View should only be rendered when needed (no patch) marked as a duplicate, but that was to simply defer executing the view until it was rendered.

This would also be an easy fix to stop DS from executing non-rendered fields as per the original request and to reduce the possibility of comment #2.

i.e. couple new theming functions and switch to using these rather than executing a full view build & render via eva_entity_view_alter()

  foreach ($views as $info) {
    $longname = $info['name'] . '_' . $info['display'];
    if (isset($fields[$longname]) && $fields[$longname]['visible']) {
      $build[$longname] = array(
        '#theme' => 'eva_results',
        '#weight' => $fields[$longname]['weight'],
      );
      $build[$longname . '_form'] = array(
        '#theme' => 'eva_exposed_form',
        '#weight' => $fields[$longname]['weight'] - 0.001,
      );
    }
  }

Implications with caching?

I don't understand this reasoning.

I don't necessarily agree that this is a good idea. For a user not using DS, your assumption that a newly created EVA view might only be wanted in a particular view mode doesn't really stand.

I was just hit by the pager issue. In my case, we had to create a couple more EVAs with the addition of a new content type. These are displayed on content types that have around 7 view modes. Each EVA will have to be enabled (because DS) and then disabled in all but the full view mode. Even in the full view mode we do not want the EVA displayed where-ever it wants. We want to tell it where to go.

So then, why not just have it disabled by default? Is #1256368: Add 'visible' key to hook_field_extra_fields() really a blocker? It seems like this should be able to be done pragmatically when adding a new EVA by just setting the visibility programmatically after creating the EVA. Is there no hook in views that allows for an operation after saving a view?