In 8.2.x, when a field is disabled under "Manage display" for an entity, the label display settings still appear to be configurable. However, the user's selection is not actually stored anywhere and therefore lost.

The label settings are lost if selected for a hidden field
(gif provided by @alexpott)

In 8.3.x following #2796581: Fields must store their region in entity displays, this also happens for the formatter selection.
Formatter settings also will be lost

This bug might not appear that impactful at first since it's for configuring fields that are not displayed, but the problem is that this also impacts the data when fields are moved between disabled and an enabled region, which results in lost input that the user did not expect.

Steps to reproduce

  1. On /admin/structure/types/manage/article/display, move the Tags field to disabled and save the form.
  2. Change the "Label" or "Format" options for the Tags field and save again. The change is not actually saved.

Proposed resolution

Do not show field settings that are not saved for disabled fields.

No formatter or label settings shown for disabled fields

The solution will need to support all three of tabledrag, non-tabledrag, and no-js workflows for the form.

A different solution would be to actually store the configured settings for disabled fields, but that would require a data model change as well, and as @alexpott points out there is also an advantage to simply having fewer options on this form.

Remaining tasks


User interface changes


API changes


Data model changes



xjm created an issue. See original summary.

xjm’s picture

Issue summary: View changes

xjm credited alexpott.

xjm credited catch.

xjm’s picture

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

capysara’s picture

Issue tags: +FLDC17

I'm going to triage this.

capysara’s picture

Issue summary: View changes
capysara’s picture

I was able to reproduce this in 8.4.x locally. Following steps in the summary:
Steps to reproduce
On /admin/structure/types/manage/article/display, move the Tags field to disabled and save the form.
Change the "Label" or "Format" options for the Tags field and save again. The change is not actually saved.

I also updated the description--changed "manage form display" to "manage display" to more accurately reflect what's reported in the gif and the steps to reproduce.

However, a similar issue exists in Manage form display when the field is moved to Disabled and the widget type is not saved.
Steps to reproduce
On /admin/structure/types/manage/article/form-display, move the Tags field to disabled and save the form.
Change the "Widget" options for the Tags field and save again. The change is not actually saved.

capysara’s picture

swentel’s picture

Status: Active » Needs review
Issue tags: +Needs tests
1.41 KB

So one option is to use the 'visually-hidden' class which really is the easiest one, but maybe not the prettiest :)

I've played with #access, but that's not an option since the javascript needs the format select element to be there. Unless we start changing that of course.

Needs tests. If we can agree on using the css trick, I can quickly write a test for it.

xjm’s picture

Issue summary: View changes
Issue tags: +Triaged D8 major

Traiged with @catch, @cilefen, @alexpott, @Cottser, and @lauriii. Since this bug is about lost user input on an administrative site builder page, it might not seem that big of a deal. However, it is lost user input, and the user does not expect it. The usability bug occurs when configuring a field in the disabled section and then moving it -- your configurations are stripped away.

Sine there is not that much to re-enter and since it impacts major fields, we discussed that it might only be normal, but it is a loss of user input further exposed by the field UI improvements, that could make your site look goofy.

Thanks @capysara for finding this issue and veriying it! Adding issue credit.

xjm’s picture

Status: Needs review » Needs work

Hm, I don't think these fields should just be visually hidden. They would still be available to non-visual browsers, making an accessibility bug. They would also be available to anything altering the form. They should not be available at all in the form, because no data is stored for them. The disabled blocks should just be empty rows until they're dragged back to the enabled block list.

sathish.redcrackle’s picture

Priority: Major » Normal

The patch dint worked for me. I checked the issue and found the below code where they are removing the compound if the field is in hidden state and not saving any value.
as @xjm suggested why we need to change the value of the field display setting which is in hidden stage? since it is not viewable to user.
So i am changing the priority to 'Normal'

      if ($values['region'] == 'hidden') {
      else {
        $options = $entity->getComponent($field_name);

        // Update field settings only if the submit handler told us to.
        if ($form_state->get('plugin_settings_update') === $field_name) {
          // Only store settings actually used by the selected plugin.
          $default_settings = $this->pluginManager->getDefaultSettings($options['type']);
          $options['settings'] = isset($values['settings_edit_form']['settings']) ? array_intersect_key($values['settings_edit_form']['settings'], $default_settings) : [];
          $options['third_party_settings'] = isset($values['settings_edit_form']['third_party_settings']) ? $values['settings_edit_form']['third_party_settings'] : [];
          $form_state->set('plugin_settings_update', NULL);

        $options['type'] = $values['type'];
        $options['weight'] = $values['weight'];
        $options['region'] = $values['region'];
        // Only formatters have configurable label visibility.
        if (isset($values['label'])) {
          $options['label'] = $values['label'];
        $entity->setComponent($field_name, $options);