Problem/Motivation

If I create an entity reference field (not file field) that can reference files, I'm able to use the default 'Rendered entity' formatter. Problem is, for files, this renders nothing. Without a module like File Entity available, entity_view() does nothing for files.

Proposed resolution

Add a isViewable() method with corresponding property to \Drupal\Core\Entity\EntityType. I tried setting 'view_builder' => NULL in the annotation for \Drupal\file\Entity\File but it breaks rendering any base fields on files, which is used for the file listing page at /admin/content/file.

Remaining tasks

* Write change notice

User interface changes

None

API changes

This adds a 'viewable' property to \Drupal\Core\Entity\EntityType, default to FALSE. \Drupal\Core\Entity\ContentEntityType overrides this with TRUE since it also is responsible for adding the default view_builder handler. No change in behavior.

Ok, so having a view_builder handler is important for building base fields, but not the entity itself. Therefore we should just add a 'viewable' property to EntityType so that the file class can override this.

The following Content Entity types are currently possible to render with the Views plugin, and demonstrates Files are not the only problem here. Note some of these are config entities that actually have view_builder classes (like Tour) and those are ok.

We probably would need to add the same restriction to Custom menu links and Shortcut links in addition to files. Neither of those actually render correctly.

Also, really strange that I can reference config entities (tours for example) with an entity_reference field, but since it provides a view builder class, I can select a formatter with a view mode. Problem is, they don't support view modes at all.

I think we need some way of distinguishing three different kinds of viewable states of entities

Entities that cannot be rendered

Config Entities that can be rendered, but not using view modes

Content entities that can be rendered

If I'm using an Entity Reference field with the 'Rendered Entity' formatter, the corresponding behavior for the above conditions should be:

Entities that cannot be rendered: The formatter should not even be available.

Config Entities that can be rendered, but not using view modes: The formatter should be available, but no view mode option should be visible. I guess it would be ok to only have 'Default' view mode as an option here as the current behavior. I think end users may be confused that they cannot create arbitrary view modes for these entity types.

Content entities that can be rendered: Current behavior

Would it be possible a content entity that can be rendered but doesn't support view modes?

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

The core committers and entity/field API maintainers discussed this issue today and thought that while this is an obvious bug (and silly), it does not need to be major because:

You can't really run into it by itself in core without a contrib module.

Contrib that is affected can already special-case it (so it seemed like more of a contrib soft blocker).

Lacking that, site builders will quickly see the formatter does not work as expected and can select a different one (like the filename).

It's possible we've overlooked something though. @Dave Reid (or anyone else), if it's problematic to work around this in contrib, can you update the issue with that information and re-promote it to major? Thanks!

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)