With 'extra fields display' out of variables, what's remaining in field_bundle_settings() is the info about :
"for each entity type & bundle, which view modes are 'specialized' and which use 'default'"

We should :
- move that info to CMI,
- get rid of field_bundle_settings()
- have an upgrade path

Comments

yched’s picture

yched CreditAttribution: yched commented
Title: Convert view modes config to CMI » [EntityDisplay] Convert view modes config to CMI

title

yched’s picture

yched CreditAttribution: yched commented

Oh, wait - we still have the settings for extra fields in forms, in there.
We know we'd need to have an EntityDisplay for forms too, but that's outside the scope of our initial patch.
Crap.

Well then, it means those 'settings for extra fields in forms" need to stay in the variable for now.
We should still take out the stuff about view modes, and move those to CMI, but field_bundle_settings() and the variables themselves need to stay for now.

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

In light of #1782460: Allow to reference another entity type to define an entity type's bundles

I wonder whether we shouldn't introduce a "formal" Bundle Configuration Entity Type; i.e., this:

namespace Drupal\Core\Config\Entity;

class EntityBundleBase extends ConfigEntityBase

...and now the tricky part:

This base class for all bundles would have public entity properties for the entity bundle settings that are expected + required for all entity bundles.

Thoughts?

yched’s picture

yched CreditAttribution: yched commented

Hm. I'd say why not, but I'd be very wary of extending the scope of the EntityDisplay patch :-).
It seems selling it as post Dec 1st stuff is not going to be easy...

So it's either:

- We move the current "list of 'specialized view modes' for a bundle" to CMI, and possibly merge it later with such an EntityBundleBase class.
I'm not sure exactly whether this should be a ConfigEntity or a plain CMI file, though. What are the rules exactly ?

- We punt for this issue, and leave those in the ugly field.module-owned variable for now, and leave that for followup cleanup.
In turn, this means that the EntityDisplay patch can't be sold as "it includes a CMI conversion, good for post freeze"...

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

In that case, I think I'd rather opt for punting on it for now, and performing the conversion into whichever bundle/config solution after feature-freeze.

gdd’s picture

gdd
he/him
Primary language English
Location Portland, OR
CreditAttribution: gdd commented
Issue tags: +Configuration system
moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

Feature request if this ever proceeds - we really need descriptions for view modes. It helps to have notes about why a view mode exists. An example is the new compact mode on the user entity. Thats for user pictures on nodes/comments.

yched’s picture

yched CreditAttribution: yched commented

@moshe : that's rather for #1043198: Convert view modes to ConfigEntity.
This issue is not about the definition of existing view modes, but about the place where we store configuration like "for article nodes, I'll configure dedicated display settings for 'rss' mode, but simply reuse the 'default' for 'print' and 'search_index' modes" - i.e the "custom display settings" checkboxes at the bottom of the "Manage display" tab.

yched’s picture

yched CreditAttribution: yched commented
Status: Active » Closed (won't fix)

As per #4 - #5, this won't be done as part of the EntityDisplay patch.