Fix confusion in UI when no CE display exists

I just woke up to the thought of "what ) wrote in this isssue is fundamentally wrong".

It's possible that I was having a mental meltdown (somehow caused by trying to upgrade an internal project and misinterpreting details about why we precreated CE displays inside it, using a beta version several months ago).

I believe there may be something here about "printing a message when a CE Display doesn't actually exist yet", but it is likely minor.

Basically I need more information from my future self.

I un-confused myself and rewrote the summary to reflect the actual issue.

I want to fix this now; it's going to save me time and confusion while working on actual projects.

I've created an MR and will set it to Needs Review for the message / as an FYI, but actually, I will already push this to the main branch.

Because I need it, and because I've already pushed so much form-message changes anyway.

I will still handle requested changes to the message.

On a fresh Core install (e.g. lupus-decoupled), Core auto-installs entity view displays for Default, Teaser and RSS, so the warning shows up. It's a lot of screen space, but... the warning IMHO is really necessary (and it refers to the info message so that it itself can be shorter).

Tweaked message a bit - this is now what is showing on a fresh Core install for articles.

If we don't want to have this message on lupus-decoupled, then we can ship a default CE display for each Core node bundle (and perhaps a CE display for the 'full' view mode too, if we need it). But I guess that's a followup that could wait until we implement proper output for Drupal CMS content types.

I think the message is bad for UX since users opening the screen the first time will have to read it and try to parse/understand what it means for that. Given this, I think for UX we should try hard to avoid this. Also this is not a pattern core introduced anywhere and it'S ususally good to follow core patterns in contrib.

I must say I'm not fully understanding why this message is needed and why it's confusing without. Why is it important whether the configuration you see is acutally saved or not? It should not matter, because either way the same configuration should be applied.

major: if they press the "Save" button without doing anything else, the output will likely change for any view mode that has its own entity view display (because it will be based on the default CE display, from then on).

I cannot follow, could you elaborate what changes? Does core face the same problem?

I cannot follow, could you elaborate what changes?

Situaition: on a certain bundle, you have

• entity view displays enabled for 'default' and 'full' view modes;
• no CE displays

In this situation, custom elements in 'full' view mode will be bult based on the 'full' entity view display. (CustomElementGenerator::getEntityCeDisplay() will auto-create a CE display that is based on 'full'.)

This IMHO is the only logical behavior, and it's v2-compatible.

However,

1. this fact is not visible in the UI. You only see the one "default" (auto-created) CE display, and no tab/local tasks for "Full" etc.
2. as soon as you save the default CE display, this behaviour changes. Custom elements in 'full' view mode will be bult based on the default CE display. This also IMHO is the only logical behaviour.

I am just thinking about this now...

1. can be fixed by showing CE displays in the UI (auto-created if they don't exist), for _all_ view modes that have an entity view display... when the default CE display is nonexistent / disabled. This likely only needs a change to the RouteSubscriber, to also show routes to $path/ce-display/{view_mode_name} if no 'default' CE display exists and the "$view_mode" entity view display exists.
2. can be fixed (only in the UI form) by, if a default CE display is saved for the first time, at the same time also saving those auto-created displays. Then the behaviour doesn't change for those view modes.

That's a whole lot of 'invisible' behavior, so I wouldn't implement that without your agreement... but it feels doable, without introducing extra problems. (Just added the code complication, but that's contained to the UI form.)

I added to the bottom of my previous comment, saying "However, 2. is not perfect for many use cases, either. "