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

More context

  • Display modes can be created per entity type, and display config is created per entity type, bundle and display mode (node.article.teaser).
  • There is a pseudo Default display mode but it's not a config entity and cannot be deleted or disabled.
  • A Default entity display is created when fields are added through field UI, or the default display is saved.
  • Entity display config can be deleted using drush cdel or config import, not through UI.
  • If a specified display config doesn't exist or is disabled, it falls back to Default.
  • If Default doesn't exist, a fallback is derived from base fields and extra fields that define display options in code (but not configurab fields added in field UI).
  • When new fields are added in the UI, they are added to the Default display as visible, but disabled in others.
  • Some display selectors use getViewModeOptionsByBundle(), which only include enabled displays.
  • Some display selectors use getViewModeOptions(), which returns all entity view modes, even if a display doesn't exist for a bundle.
  • Main entity displays define different "Full" displays: "Full content", "Full", "Taxonomy term page", "User account".
  • Layout builder overrides use Full display when enabled, or Default otherwise.

Confusing

  • If Full display is enabled, new fields only go to default and are easier to miss.
  • Selecting a view mode without knowing enabled displays for the bundles and fallbacks is error prone.
  • Hard to tell which is the main display in use in manage display.
  • Layout builder override option moves from Default to Full if full is enabled.

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

Remaining tasks

Review UX issues and decide how to proceed

User interface changes

API changes

Data model changes

Comments

Berdir created an issue. See original summary.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#2639274: Unable to select "default" pseudo view mode in FieldFormatterFromViewDisplay configuration
wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

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

berdir’s picture

berdir
Primary language German
Location Switzerland
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 🇧🇪🇪🇺
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
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
he/him
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 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 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
Primary language German
Location Freiburg, Germany
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.

lauriii’s picture

lauriii
he/him
Primary language Finnish
Location Finland
commented
Related issues: +#3483304: Add support for disabling a route for a node-type

I was working on #3483304 and realized there's overlap with this issue. I don't think we should introduce the concept of locked view modes. For micro-content we'd want users to be able to delete the Full view mode entirely.

Given that, here's a proposal:

1. Copy "Default" display to "Full" display for existing sites

For BC, provide an update hook that copies core.entity_view_display.*.default configs to *.full when a Full display doesn't already exist.

2. Stop creating "Default" display for new content types

New content types would only get a "Full" display — no "Default" at all. This means new sites and new content types are immediately on the new structure with no legacy baggage.

3. Make "Default" display deletable

Allow existing sites to delete their "Default" displays once they've confirmed it's no longer being used. This lets sites migrate at their own pace.

4. Introduce internal fallback rendering (code-only, not config)

When a requested view mode has no "Default" display, render a warning message with a link to create/enable the missing view mode. This is purely code (i.e. no config entity, no view mode in dropdowns or exports).

Something like:

The view mode 'card' is not configured for this entity type.
[Link to create it]

With these changes, deprecation would look like this:

  • 11.x: Copy default→full for existing, stop creating default for new bundles, allow deletion, update UI to show Full as primary
  • 12.x: Remove Default from Manage Display UI entirely
  • 13.x: Remove "default" view display support from config loading

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

mortona2k’s picture

mortona2k commented
Issue summary: View changes

Updated summary with additional context about how it works and where the confusion is.

I think we should keep default and full. Full works for the main content display, and Default is for undefined displays that are configured or hardcoded. What if overrides worked similar to views displays, where field config could be inherited or overridden?

* Remove Default, make Full the fallback

Keep it - let's us configure defaults instead of a derived fallback and is copied for new displays.

* 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

This could lead to mistakes without some assistance to help you configure missing displays.

* Have a full view mode that always exists for all entity types

Consolidate and standardize existing ones.

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

How about better syncing of field settings instead? For example, an option on the field add form to add it to displays. Or an option to reset a display's field settings to default or another display?

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.

Standardizing the Full/main display name would help, and inheriting field settings from Default.
We can just not enable the full display, and it falls back to default.

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

Fallback order needs to be clarified to site builders, and the hardcoded uses seem tangled.

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.

Unsure if you mean the display mode settings are clearer in views UI, or the way views display overrides work.
Views UI settings list all display modes, so it can be very confusing to configure.

#20 Given that, here's a proposal:

I think this all still fits if we make default deletable and add a fallback. The Default display can be deleted already, but the pseudo display mode remains in the UI.

Does removing default improve the UX? We are forced to specify display modes or get a fallback, but there is no way to set defaults for new displays. Consider if default display settings could be inherited in other displays.

Can we add more context to where the display modes are selected to help avoid misconfiguration, and a message or status report for missing displays?