Add separate 'Save' and 'Save and add fields' to Add Content, Comment, Media and Block Type Forms

Alternatively:
Only the 'Save' button for each of the 4 entity types' add form
or
Only the 'Save and add fields' button for each of the 4 entity types' add form

Chris Matthews, Patch '3365229_8.patch' fixes the issue. Please review.

Updated patch '3365229_8.patch' --> '3365229_11.patch' as per coding standards.

Issue was started in an MR on the correct branch and should continue there.

MR should be reviewed though.

The changes here are pretty straightforward. Most of it is refactoring the button labels from 'Save content type' to 'Save' which is fine to do IMO since the added "manage fields" button will provide sufficient context clues regarding what the "Save" button means.

1. It looks like there's a dedicated form_alter and submit handler for each of the relevant entity types, but the logic in each is largely the same. The alter can probably be consolidated into a single function like
   

   function field_ui_form_alter(&$form, FormStateInterface $form_state, $form_id) {
     $forms = ['node_type_form', 'media_type_add_form', 'block_content_type_add_form', 'comment_type_add_form'];
   
     if (!in_array($form_id, $forms)) {
       return;
     }
     // We want to display the button only on add block type form.
     if ($form_state->getFormObject()->getEntity()->isNew()) {
       $form['actions']['save_continue'] = $form['actions']['submit'];
       $form['actions']['save_continue']['#value'] = t('Save and manage fields');
       $form['actions']['save_continue']['#weight'] = $form['actions']['save_continue']['#weight'] + 5;
       $form['actions']['save_continue']['#submit'][] = 'field_ui_form_manage_field_form_submit';
     }
   }
   

   The only difference in the submit handlers (I think... double check) is a string that is available via form state, so it could be something like

   function field_ui_form_manage_field_form_submit($form, FormStateInterface $form_state) {
     $provider = $form_state->getFormObject()->getEntity()->getEntityType()->getProvider();
     if ($form_state->getTriggeringElement()['#parents'][0] === 'save_continue' && $route_info = FieldUI::getOverviewRouteInfo($provider, $form_state->getValue('id'))) {
       $form_state->setRedirectUrl($route_info);
     }
   }
   
   

2. I didn't see any test coverage for the newly added Save and Manage Fields buttons. I imagine it can be integrated into existing tests. Just a verification that submitting it takes the user to the correct field ui form is probably sufficient.

I did a little bit of cleanup on the MR and I think it's ready to RTBC, but I noticed it has the Usability Review tag. The first paragraph in #13 explains why we think this is an OK change, but I pinged @ckrina to get a more official signoff on that.

I like the idea of separating this button in 2 so a user can decide which is the next step, but I see some problems with the current result: now there are 2 main actions, when in a form there should be only 1. For example, in the form to create a node we have the "Save" action as the primary one (with the blue Primary button styles) and then the Preview with the regular button (gray styles). So in here the Primary action should be defined so we don't have 2 blue buttons together and we "suggest" the next step highlighting the one that makes more sense.
I'm inclined to the "Save and add fields" as the primary one because this way we'd be leading a newbie to the reasonable and handy next step, but the other one would make sense too. So no strong opinion from me about which one. Just let's be sure that there is only one primary button :)

Good call @ckrina. I'm happy to provide a strong opinion on which one to use :-D

Is the issue about inconsistencies or about workflow? Lets not fix inconsistencies by introducing workflow changes, or at least be clear about how these impact eachother :)

Not saying it wouldn't be useful to add the "and manage fields" option, but then that should probably be the only button. I notice that editing an existing content type has just "save" and that's fine. So for content types we really are in the specific context of creating a new thing that very likely needs further work in setting up fields. If the same situation (editing existing is a different screen than creating a new one) applies to creating new Comment, Media, Block types, than "Save and manage fields" could well be the only primary button there.

Is the issue about inconsistencies or about workflow? Lets not fix inconsistencies by introducing workflow changes, or at least be clear about how these impact each other

Great comment! I originally submitted the issue with both consistency and functionality in mind, with functionality (from a site builder's perspective) taking a bit higher priority between the two. With that said, it's definitely not work fixing inconsistencies if it unintentionally causes other issues, so we may need a full review from the UX team before proceeding.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

I was initially leaning to having just the one button "Save and manage fields", but in Slack, @ckrina correctly pointed out that managing fields is not always as important a next step for media, comments. So, lets do a "Save and manage fields" as the first and primary button, "Save" as the secondary button.

Manually tested, changes look good and looks like usability review feedback is addressed so removing tag.

Confirmed with @narendraR on Slack that the change I pushed looks good for him.

Committed 64e10df and pushed to 11.x. Thanks!

lauriii → closed merge request !4246

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