Problem/Motivation

We have a number of issues around the confusing situation with Full/Default:

* #2834316: Node preview shows and defaults to "Default" instead of "Full" view mode
* #2639274: Unable to select "default" pseudo view mode in FieldFormatterFromViewDisplay configuration (not core, but relevant feedback from @yched)
* #2700147: Views uses non-existent "default" view mode, which causes Quick Edit to break

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. The default view mode is "full" and there is often now view display enabled for it. And our API returns 'default' as fixed always-there default option instead of "Full".

Proposed resolution

@todo: Complete this, just some notes/ideas for now:

* Remove Default, make Full the fallback
* Maybe no fallback at all, no enabled display => no fields. Without a hierarchy of fallbacks, it is in 95% of the cases not what you want anyway
* Have a full view mode that always exists for all entity types
* Have locked view modes that can't be deleted

Maybe some changes can be done as improvements in 8.x, but changing the fallback concept and renaming default to full is IMHO 9.x only.

Remaining tasks

User interface changes

API changes

Data model changes

Comments

Berdir created an issue. See original summary.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Related issues: +#2639274: Unable to select "default" pseudo view mode in FieldFormatterFromViewDisplay configuration
Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented

FWIW: this came up on Twitter again: https://twitter.com/marcvangend/status/840148831270449152.

Berdir’s picture

Berdir
Primary language German
Location Switzerland
CreditAttribution: Berdir at MD Systems GmbH commented

I assigned this to 9.x because it is a breaking change for configuration.

Now that 9.x has to be backwards compatible, I don't really know how to make the switch to not having a default view display.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers at Acquia commented
Version: 9.x-dev » 8.7.x-dev
Issue tags: +Drupal 9

We have to figure out how to do this in 8. Perhaps our experiences in the past 2 years as a community have given us the insight how to do this in a BC way now.

andypost’s picture

andypost
he/him
Primary language Russian
CreditAttribution: andypost as a volunteer and at Skilld commented
Related issues: +#2923701: Mechanism to disable preprocessing of node base fields so they can be configured via the field UI

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

ressa’s picture

ressa CreditAttribution: ressa at Ardea commented

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.

dalemoore’s picture

dalemoore CreditAttribution: dalemoore commented

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/it’s named that.

I don’t know that naming it full content is accurate. I can create a ton of fields and on the default or full mode display some fields that may not appear in some other view mode, or vice versa. For a paragraph, for instance, I might have a drop-down field to select a view mode on one display but not have that field on another display.

To me it makes sense to do the opposite, get rid of Full and keep Default. I have rarely ever enabled 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.

joachim’s picture

joachim CreditAttribution: joachim as a volunteer commented
Issue tags: -Drupal 9

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().

geek-merlin’s picture

geek-merlin
they/omg
Primary language German
Location Freiburg, Germany
CreditAttribution: geek-merlin at Geeks4Change, MachbarMacher commented

@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.