- Issue created by @wim leers
- Assigned to lauriii
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
I suspect/hope @lauriii has done some thinking around this already?
- 🇳🇿New Zealand john pitcairn
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. - 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
- 🇬🇧United Kingdom longwave UK
+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.
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
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 :)
- 🇬🇧United Kingdom longwave UK
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?
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
#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.
- Status changed to Postponed
4 months ago 11:14am 20 August 2024 - 🇳🇿New Zealand john pitcairn
#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).
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
@john pitcairn Thank you! Very insightful comment :)
- Assigned to wim leers
- Status changed to Active
2 months ago 2:58pm 21 October 2024 - 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
This is in scope for 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active .
Discussed with @lauriii earlier today.
Expect a push forward tomorrow, with a concrete proposal.
- 🇫🇮Finland lauriii Finland
We still need this but isn't this pretty simple in the 0.2.0 scope because of 🌱 [Research] Landing page integration Active ?
- 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
Yeah this was my #1 next thing but then our baby came two days early 😅
Has the scope for
0.2
been narrowed to focus only on this newPage
content entity type?If so, then:
- yes, we can just hardcode this for now, and we can postpone this to
0.3
instead. - can you please update 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active to capture this significant scope change? 🙏
- yes, we can just hardcode this for now, and we can postpone this to
- 🇺🇸United States effulgentsia
Has the scope for 0.2 been narrowed to focus only on this new Page content entity type?
Yes.
can you please update 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active to capture this scope change?
Done.
we can just hardcode this for now, and we can postpone this to 0.3 instead
In addition to postponing this to 0.3, we might learn that we don't need to do this at all, because for 0.3 we'll support editing all fields, so might not need to classify them as metadata vs non-metadata.