- 🇩🇰Denmark ressa Copenhagen
This would be a nice improvement. I am currently building a site, and feel like I need to update both "Default" and "Full" to not run into problems down the line ...
Removing Default, and make Full the fallback would be great.
- 🇺🇸United States dalemoore
What does “Full” even mean? I know when you go to the screen you can tick the “Full content” box and give it its own view mode settings, but I’ve hardly ever done that. Not sure what “full content” means here. Is it all available fields? Doesn’t seem so. I’d love some context behind why it exists.
To me it makes sense to do the opposite, get rid of Full and keep Default. I have rarely ever enables the Full content view mode personally, instead using the Default and creating new view modes as needed for teaser, cards, whatever. Makes more sense to me to have a Default view mode, which is a fallback when no other mode applies and is the “standard view” for that content type.
- 🇬🇧United Kingdom joachim
Just been bitten by this. It's really hard to understand!
$entity_display_repository->getViewModes('node'); returns a list that contains 'full', but not 'default'.
But in the display admin UI, it's called 'default', and the config view display is called 'node.BUNDLE.default'.
But the CSS class on the viewed node says 'full' and the view mode in hook_entity_display_build_alter() is 'full'.
So... I think what's happening is that the 'full' mode is being requested, but that's not enabled, i.e. the 'full' view mode's status is 'false', which means in the admin UI it's not set to have custom display settings. So 'default' is being used as a fallback, but it's being presented *as if it were 'full', hence the CSS class and the view mode in hook_entity_display_build_alter().
- 🇩🇪Germany geek-merlin Freiburg, Germany
@joachim: Like the IS states, and just like in Views, 'default' is the universal fallback:
The main problem is that we have view displays and view modes and there is a default view display that is a fallback for all view modes that have no display enabled.
Maybe it's mori intuitive UI-wise in views than in field UI. Also, there's maybe more use for this in a complex view.
I like the proposal from the IS, but it'll be quite a deprecation and update dance.