Problem/Motivation

Current Entity override has some UX and workflow issues:

  • The UI Patterns field creation:
    • Cardinality unlimited should be required (or notify)
    • Field created must be hidden from form display (or notify to do so)
    • Must force the default display profile to enable the override
  • An instance is created as soon as tab is clicked on an entity,
  • If no default display is published, the override display s empty on start

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Issue fork display_builder-3562686

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

mogtofu33 created an issue. See original summary.

mogtofu33’s picture

mogtofu33 commented
Related issues: +#3541151: Content display overrides: Form widgets
mogtofu33’s picture

mogtofu33 commented
Priority: Normal » Major
Issue tags: -display_builder-1.0.0-beta1 +display_builder-1.0.0-beta2

ipumpkin made their first commit to this issue’s fork.

pdureau’s picture

pdureau commented
Issue tags: -display_builder-1.0.0-beta2 +display_builder-1.0.0-beta4
pdureau’s picture

pdureau commented

See also #3541151: Content display overrides: Form widgets

ipumpkin opened merge request !227

pdureau’s picture

pdureau commented

Sorry for the late feedback:

Cardinality unlimited should be required (or notify)

Not really. Cardinality should still be configurable at the field level (because we will do #3544026: Cardinality & suggested components constraints for slots) but it must be "Unlimited" by default.

ipumpkin’s picture

ipumpkin
Primary language Chinese, Simplified
Location China
commented
Status: Active » Needs review
mogtofu33’s picture

mogtofu33 commented
Assigned: Unassigned » mogtofu33
pdureau’s picture

pdureau commented

An instance is created as soon as tab is clicked on an entity,

Which tab are we talking about here? Which route?

mogtofu33’s picture

mogtofu33 commented

Some discussion for more work here:

  • Choice to override should be a checkbox
  • When clicked option to select profile
  • On save The field is created automatically, taking care of field_prefix config.
    • to decide: field locked?
  • Then we display as readonly the selected field

If an other manual field UI Patterns is created, no change.
If UI Patterns is created before override of after enable/disable override, do we offer select?

There is the case of deletion, entity delete is taken into account in hook but not field delete, if the manually create UI Patterns field is selected, but then deleted, what do we do?

mogtofu33’s picture

mogtofu33 commented
Assigned: mogtofu33 » Unassigned
Status: Needs review » Needs work
pdureau’s picture

pdureau commented
  • Choice to override should be a checkbox
  • When clicked option to select profile

What is the purpose of the checkbox if there is a profile selection (which is the mechanism to activate display builder everywhere else) ? Do we save the boolean value of the checkbox somewhere in config?

On save The field is created automatically, taking care of field_prefix config.

What about if there is already an available source field to take? Some power users may want to manage their content model themselves?

Then we display as readonly the selected field

OK

Here is my proposal, which is keeping the 2 main benefits of yours (automatic field creation and readonly field select after config save) while keeping the existing features:

  1. Add a new option in the field selection " - Create automatically -":
    • if there is already available fields, it will just be the default option and site builders can pick another one (among the ones not already used for overrides, as it is the case today)
    • if there is no  fields available, it will be the only option
  2. After submit, the select becomes readonly, we can't change the value. However, if the override is removed from the display (by un selecting a profile) we must allow the selection again if someone reactivate the override later.

What do you think about this? We need to find the sweet spot between improving the ease-to-use without losing power-user features.

mogtofu33’s picture

mogtofu33 commented
Assigned: Unassigned » mogtofu33

The profile selection (override) can not save a checkbox.
I pushed an evolution, need work as the field options is across entities and not the current bundle only. Guess we can keep the same field config storage.

We still lack the disable behavior, we keep the field but then should inform somehow.

  • mogtofu33 committed 9dea2f88 on 1.0.x authored by ipumpkin 
    feat: #3562686 Entity view override enhancements

By: mogtofu33
By:...
mogtofu33’s picture

mogtofu33 commented
Assigned: mogtofu33 » Unassigned
Status: Needs work » Fixed

Seems ok for now, we'll see if needs to adapt in a follow up issue.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.