Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Currently, entity_view()
uses an heuristic based on the path to determine whether the entity is viewed in page mode
or not. It matches the way Drupal core does it, which has already been determined as a bad idea (see #721754: A node cannot be displayed in different view mode on its own page).
I suggest we allow this mode to be set by the caller, or automatically determined by view mode. After all, most of the time this is what you want (I would argue that the 'full' mode for core nodes has very little use outside a full page context).
Comment | File | Size | Author |
---|---|---|---|
#9 | entity_page_follow_up.patch | 569 bytes | fago |
#6 | 1208864-page-mode-entity-rendering.patch | 5.37 KB | Damien Tournoud |
#3 | 1208864-option-1.patch | 4.58 KB | Damien Tournoud |
#1 | 1208864-option-1.patch | 4.58 KB | Damien Tournoud |
#1 | 1208864-option-2.patch | 2.88 KB | Damien Tournoud |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedI see two options:
Option 1. Implement something close to what Drupal 6 was doing: add an explicit
$page
argument toentity_view()
. The old behavior is kept when this argument is not present. We can even make this completely backward compatible if we don't change theEntityAPIControllerInterface
interface (but I would recommend modifying it).Option 2. Allow the view mode to explicitly say that they should be displayed in full page, by adding a new key to the view modes array.
I would recommend option 1. Option 2 seemed like a good idea when I wrote it, but I think leaving the caller decide is the best we can do.
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedComment #3
Damien Tournoud CreditAttribution: Damien Tournoud commentedReuploading option 1 to fix a typo.
Comment #4
pounardEntity view returns the build array, so Option 2 still let the caller decide, but Option 1 seems less confusing. Maybe the two could be done and optional, one overriding the other.
Comment #5
fagoI agree that ideally the caller should be able to decide upon this.
With option2 one might end up with viewing in page-module if people re-use the view mode somewhere else, e.g. from a view. In most cases that's probably unwanted behaviour then, so let's require $page to be explicitly set (option1)
@patch:
* Problem is entity_view() also serves as harmonized entity_view() for core entities, where this option does not exist. So we'll need to document that this option only works for entities provided via the EntityAPIControllerInterface.
* Also, we need to document the default behaviour of guessing if NULL "is passed".
* It's a bit unfortunate to have another API change, but most people should use or extend the provided controller anyway - beside you.. ;) So I guess it should be ok.
For d8, I think we should migrate entity_view() to take a $options array like many other functions.
Comment #6
Damien Tournoud CreditAttribution: Damien Tournoud commentedRerolled, based on comments from #5.
Comment #7
fagoThanks, committed.
-> We have an API Change for EntityAPIControllerInterface::view():
Modules that override the method of the default controller or implement the interface themselves have to follow the following change:
Comment #9
fagoAS #1210806: Add corollary to node_is_page() has shown, we forgot adding $page to Entity::view().
Doing so is an API change. However usually modules should override buildContent() not view(), so it should be ok.
Comment #10
tim.plunkettCouldn't be more straightforward.
Comment #11
Damien Tournoud CreditAttribution: Damien Tournoud commentedYes, sorry about that.
Comment #12
fagoCommitted.