[later phase] [RESEARCH] How to identify all meta fields for an arbitrary content entity?

I suspect/hope @lauriii has done some thinking around this already?

Whatever solution is chosen should allow site builders to flag any field as a meta field, whether that's a core field, contrib field, or field they have added in the UI. We shouldn't make any assumptions about existing fields or field types.

• A site builder may add a core media reference field that will never be displayed in the layout, but is used to set the canonical entity display og:image header meta element for social media previews. That shouldn't appear as a layout component, it's definitely a meta field from an author's point of view.
• A site builder may add a contrib location field that will not be used to display a map, but will be used to contextually filter other content available on the entity display via views block components which were placed by XB (ie you don't want to have to specify the location in every one of those components).

My preference would be option 1 or 2: an additional setting exposed in the UI for each field instance form, or for each form display widget setting. Option 1 might be better for supporting decoupled edit forms, not sure.

I don't like option 3. This is generically very useful and shouldn't be tied to XB – admin themes could use it to move those elements into their entity form meta group, instead of hard-coding "known" meta fields in a form_alter() and requiring a site dev to move any others via the same fragile mechanism.

+1 for not making this specific to XB, it could be useful elsewhere.

To decide between options 1 and 2: is there a reason why some fields would be metadata in some form layouts but not others? I can't think of anything immediately which would point to option 1, but if there is, then option 2 would let us distinguish that.

Whatever solution is chosen should allow site builders to flag any field as a meta field, whether that's a core field, contrib field, or field they have added in the UI.

+1 for not making this specific to XB, it could be useful elsewhere.

Absolutely. I was shocked to discover this does not exist yet!

I don't like option 3.

Me neither. But changing core can be slow. Option 3 is the "last resort, and if so, short-term only" option.

Now let's hear from @lauriii :)

Is it possible to naively identify meta fields by finding all fields that are not displayed in any view mode? This probably doesn't hold true for all cases, but generally, if a field is never displayed it must be meta information of some kind?

#7: Ohhhhh!!!!!! 🤔 I think that would mostly work currently. But I think that indeed it is probably not universally true. That could be a viable initial heuristic though!

Running with that over at #3463988-9: HTTP API: new /xb/api/entity-form/{form_mode} route to load form for editing entity fields (meta + non-meta) → , and will point to this issue to identify a long-term solution.

#7: There is an issue or two somewhere that touches on current problems with that.

I wanted to extract the display config to preset and hide field formatter complexity for layout builder inline field blocks, but LB disables manage display, and if using config from a different view mode as a workaround, any disabled fields in manage display do not retain their display config (something like that).

I'll see if I can find the issue(s).

@john pitcairn Thank you! Very insightful comment :)