Allow editing page title and meta fields in XB

Can we better define "meta field"?

Site builders often add fields that will not be displayed, but do need to be edited at least once.

This begs a mechanism to opt such a field in as a "meta field". Currently this usually requires a hook_form_alter() implementation to move the field into whatever structure the theme defines as the meta group. It's far from intuitive, can't be done without code, and this seems an appropriate opportunity to fix that.

#3: I'm pretty confident @lauriii is referring to "fields with no visual representation" when he says "meta fields". Example: path alias.

An entity's title/label field is visible. Hence the title: "title and meta fields"

@lauriii: is this still assigned to you because you're workin on defining this more, i.e. are working with the Acquia UX team to get a design ready? IOW: is this blocked on design?

Yes, the meta fields is supposed to be referring to fields with no visual representation. We'll need to define how the form is structured and what is the UX for configuring it.

This is assigned to me because I'm working with Acquia UX to define the intended user experience.

👍

Matching the issue title prefix pattern I used for 📌 Clarify "components" vs "elements" vs "patterns" Active .

Increasing priority since this is part of 🌱 Milestone 0.1.0: Experience Builder Demo Active .

This blocks 📌 [PP-1] Redirect users directly to Experience Builder when creating new content or editing content Postponed .

The design currently does not answer this, but I'd previously captured this screenshot, so either I just cannot find it or it disappeared?

Either way: 📌 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 intends to allow that, but the page title is actually not part of NodeForm's $form['meta']!

We can alter that probably, but … is that really how it is intended to work?

For now (aka interim solution): #3463988-6: HTTP API: new /xb/api/entity-form/{form_mode} route to load form for editing entity fields (meta + non-meta) → .

@john pitcairn in #3: agreed, that is the right question to ask, created 📌 [later phase] [RESEARCH] How to identify all meta fields for an arbitrary content entity? Active for that 👍

There's this todo in the code linking here

// @todo Design is undefined for the DynamicPropSource UX. Related: https://www.drupal.org/project/experience_builder/issues/3459234

But this issue doesn't seem to be about UX of DynamicPropSource.

Should we repurpose it for that now we have a 'Page data' form in the UI?

From an implementation point of view it is probably simpler if we keep the form to configure whether you want to use a static prop source or otherwise outside of the component props form - just because that form is Drupal generated and we don't want to have to stitch things together.

Perhaps a link in the component props form 'configure sources' that pops up a dialog. In the dialog there's a dropdown for each prop that has the available source options (much like the original widget did in very early 0.x days). Modifying the values in that form would re-request ComponentPropsForm with new prop sources in the URL and this would trigger that form to replace the widget for the dynamic props with something else (most likely a readonly field)

#13++ Wanna do that?