Contrib.social

Lost user input when attempting to configure disabled fields on entity displays

Open on Drupal.org →
Created on 26 October 2016, about 8 years ago
Updated 13 September 2023, over 1 year ago

Problem/Motivation

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.


(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.

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.

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

TBD

User interface changes

TBD

API changes

TBD

Data model changes

TBD

🐛 Bug report
Status

Needs work

Version

11.0 🔥

Component
Field UI  →

Last updated 4 days ago

Created by

🇺🇸United States xjm

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Triaged core major

    There is consensus among core maintainers that this is a major issue. Only core committers should add this tag.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇳🇿New Zealand john pitcairn

    A different solution would be to actually store the configured settings for disabled fields, but that would require a data model change as well.

    It's pretty annoying as a site builder if you want to disable a few fields to test out some layout variation, then you re-enable them only to find you also have to reconfigure them. If you have a lot of formatter 3rd-party add-ons that's very tedious, and you will forget something.

    I also have a more advanced use case - allow layout builder content field blocks to use the configured settings as defaults, and optionally hide that whole formatter mess from site editors who are using layout builder. I've just been working on a proof of concept that stalled on this issue.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024