Contrib.social

Use the "Save and manage fields"-button pattern on all content entity types

Open on Drupal.org →
Created on 26 April 2023, almost 2 years ago
Updated 28 April 2023, almost 2 years ago

Problem/Motivation

If you are adding a new for example block type on /admin/structure/block-content/add you only have a save-button available for saving, which redirects you to /admin/structure/block-content afterwards. In comparison if you are adding a new content type on /admin/structure/types/add you have the save and manage fields-button instead which redirects you to the manage fields-page on the newly created content type.
So when you create a block type you always have an extra click where you have to manually re-enter the newly created block type (usually you don't want to create just a block type and don't configure it right away) plus it is inconsistent to the content type ux. Aside block types this applies to comment types and media types as well.

Steps to reproduce

  1. go to /admin/structure/block-content/add, /admin/structure/comment/types/add or /admin/structure/media/add
  2. add a label
  3. hit save

Proposed resolution

For consistency reasons with the node module it might be a reasonable step to change the save-button to a save and manage fields-button and redirect the user to the manage fields-page of the newly created block, comment or media type.

I've created just a single issue for the fields_ui component after consulting @aaronmchale. instead of creating a meta issue with dedicated child issue and changing the button for each module he wondered the following:

I wonder if an issue should first be opened against the Field UI module, because if the Field UI module simply injects that link into the config entity form, or if the config entity form includes something for this route, then all bundles would just benefit from the save and manage fields link out of the box.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

✨ Feature request
Status

Active

Version

10.1 ✨

Component
Field UI  →

Last updated about 2 hours ago

Created by

🇩🇪Germany rkoller Nürnberg, Germany

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Comments & Activities

  • Issue created by @rkoller
  • Comment almost 2 years ago →
    cilefen
  • Comment almost 2 years ago →
    cilefen

    I misread this post as being block_content only. Sorry.

    I would be amazed if there is not already an existing family of issues for this.

  • Comment almost 2 years ago →
    🇩🇪Germany rkoller Nürnberg, Germany

    no problem at all, and thanks for already reverting back to the field ui component.

    in regards of already existing issues i've searched before i've created the issue. i've searched another round now and looked for save and manage fieldsindividually in block content → , comment → , field ui → , and media → (before i'Ve just skimmed the whole results list with no component selected). but again i was unable to find any already existing issue.

  • Comment almost 2 years ago →
    🇬🇧United Kingdom AaronMcHale Edinburgh, Scotland

    As quoted in the IS, I'd be really keen if we can find a way to do this in a generic way, so that it's easy for both Core and Contrib to benefit from this.

    That could mean:

    1. Field UI injecting the button onto the config entity form for any config entity types which have field UI enabled (as noted in the IS, may also be a BC-break).
    2. Add some new logic to EntityForm::actions with a check and the link (possibly BC-break though).
    3. Add a new ConfigEntityForm, which overrides the EntityForm::actions method to add this button (and a check), 📌 Add an ConfigEntityForm with an exists() method Needs work is also advocating for adding a ConfigEntityForm class but for different reasons, so maybe there's a good case for doing that.
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024