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

Created on 26 July 2024, 5 months ago

Overview

📌 HTTP API: new /xb/api/entity-form/{entity_type}/{entity}/{entity_form_mode} route to load form for editing entity fields (meta + non-meta) Fixed introduced a very simple/pragmatic/naïve approach. But it won't work for all content entity types, because NodeForm happens to group all the meta fields in a predictable form location … but that's not universally true.

Unfortunately, there's no metadata (hah, ironic, right?! 😅) to identify which fields should be considered "meta".

For example, these two meta fields:

    $fields['promote'] = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Promoted to front page'))
      ->setRevisionable(TRUE)
      ->setTranslatable(TRUE)
      ->setDefaultValue(TRUE)
      ->setDisplayOptions('form', [
        'type' => 'boolean_checkbox',
        'settings' => [
          'display_label' => TRUE,
        ],
        'weight' => 15,
      ])
      ->setDisplayConfigurable('form', TRUE);

    $fields['sticky'] = BaseFieldDefinition::create('boolean')
      ->setLabel(t('Sticky at top of lists'))
      ->setRevisionable(TRUE)
      ->setTranslatable(TRUE)
      ->setDefaultValue(FALSE)
      ->setDisplayOptions('form', [
        'type' => 'boolean_checkbox',
        'settings' => [
          'display_label' => TRUE,
        ],
        'weight' => 16,
      ])
      ->setDisplayConfigurable('form', TRUE);

… do not have any discernible way to deduce that these are "meta" fields.

Proposed resolution

TBD. Options:

  1. Additional metadata at the field level?
  2. Additional metadata at the EntityFormDisplay level?
  3. XB-specific metadata, with a UI?

User interface changes

TBD

📌 Task
Status

Active

Component

Page builder

Created by

🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @wim leers
  • Assigned to lauriii
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺

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

  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇳🇿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.

  • 🇬🇧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
  • 🇧🇪Belgium wim leers Ghent 🇧🇪🇪🇺
  • 🇳🇿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
  • 🇧🇪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 new Page content entity type?

    If so, then:

    1. yes, we can just hardcode this for now, and we can postpone this to 0.3 instead.
    2. can you please update 🌱 Milestone 0.2.0: Experience Builder-rendered nodes Active to capture this significant scope change? 🙏
  • 🇺🇸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.

Production build 0.71.5 2024