Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.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.
A node with a entity reference field referencing a file:
No output visible
HTML output showing nothing:
We have to special case file entities in Entity Embed, but my concern is that other things may try to render entities that have a view builder class, but are not actually viewable.
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.
Data model changes
None
Beta phase evaluation
| Issue category | Bug because users are tricked into using a formatter that cannot be used. |
|---|---|
| Issue priority | Not critical because most people will use file fields, but this affects contributed modules like Entity Embed. |
| Unfrozen changes | Unfrozen because it solves something that never worked in the first place. |
| Disruption | Disruptive for any contrib modules that had un-viewable entities that used ContentEntityType. Of my knowledge there are no such contrib modules, and core's file module is the only known example to me. |
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | Selection_302.png | 70.02 KB | dave reid |
| #9 | interdiff.txt | 1.04 KB | dave reid |
| #9 | 2567919-file-entity-disable-view-builder.patch | 4.32 KB | dave reid |
| #2 | 2567919-file-entity-disable-view-builder.patch | 494 bytes | dave reid |
| Selection_295.png | 26.34 KB | dave reid |
Comments
Comment #2
dave reidComment #3
dave reidComment #6
dave reidOk, 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.
Comment #7
dave reidComment #9
dave reidAlso found that Views offers a 'File' entity row plugin which suffers the same problem. By adding a isViewable() method, it helps simplify this.
Also last patch was invalid, sorry.
Comment #11
dave reidComment #12
dave reidComment #13
dave reidBumping priority as this is broken functionality in core.
Comment #14
dave reidThe redirect module will also want to use ContentEntity, but not have them as "viewable" and will need this functionality.
Comment #15
dave reidComment #16
chx commentedDo we want base entities to be not viewable by default....? If I remember correctly, for example, menu links are not content entities and yet viewable.
Comment #17
dave reidBase entities are not viewable by default I thought, since they don't actually have a default value for view_builder. It's only ContentEntityType which adds the default view_builder class.
Comment #18
dave reidThe 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.
Comment #19
dave reidAn alternative to this is to not merge in the default view_builder class in ContentEntityType and make each entity type declare its view_builder class itself (even if it's the default).
Comment #20
yched commentedTotally agree that ConfigEntities should not be considered viewable.
One weirdness being that Block config entities have a ViewBuilder...
Comment #21
dave reidNot sure how to get feedback on this from someone higher up on this... since it involves changing/adding an API and is a contributed project blocker.
Comment #22
yched commented@Dave Reid : maybe ping @timplunkett ?
Comment #23
wim leersPatch looks great!
ContentEntityTypedoes this:i.e. it assigns the default entity view builder to every content entity type. Wouldn't you also want to change this then?
Why not just
$this->viewable?It defaults to
FALSEso will always be set.Nit: Extraneous newline here.
Comment #24
dave reidAlso, 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.
Comment #25
dave reidI think we need some way of distinguishing three different kinds of viewable states of entities
If I'm using an Entity Reference field with the 'Rendered Entity' formatter, the corresponding behavior for the above conditions should be:
Would it be possible a content entity that can be rendered but doesn't support view modes?
Comment #26
catchNot sure the new title is perfect, but trying to get it a bit closer to the patch. Also moving to entity system.
I don't think the last question in #25 is possibly at the moment, so the 1/2/3 case should be all we need to deal with.
Comment #28
xjmThe 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:
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!
Comment #39
smustgrave commentedI don't think this is an issue anymore. 'Rendered entity' formatter doesn't appear to be option anymore. Would like to close as outdated.
Comment #40
larowlan#2204325: The "rendered entity" formatter breaks for entity types with out a ViewBuilder added
\Drupal\Core\Field\Plugin\Field\FieldFormatter\EntityReferenceEntityFormatter::isApplicablewhich limits this formatter to entities with a view-builder.