Problem/Motivation

When changing the field formatter for a field for an entity display, you are not prompted to configure the field. As for the configuration form for the field is not displayed, it's possible to save a field configuration that is configured incorrectly, meaning that the formatter in the best case, wont be able to work, or might otherwise cause errors. We've seen this with responsive image formatter in core, and in contrib it's probably going to be much worse.

Steps to reproduce

For core only - you can reproduce this for responsive image formatter like this:

1. Install Drupal core standard and enable response image module.
2. Delete all predefined responsive image styles
3. Configure image field on article (field_image) to use responsive image formatter
4. Click save
5. Notice, configuration has been saved which should look like this:

select config
bad config

Proposed resolution

There are two general approaches for this.

1. Add a validateConfiguration method on formatters that they can implement if validation is needed, in order to ensure that the configuration going to be saved is valid.
2. Display the form of the formatter when changing formatter for a field. This approach is very user friendly as the user is prompted to configure the formatter when changing formatter type. However, this is requires a pretty big change in the form layout, styles and javascript, as we probably would want to allow the user to change formatter again if the formatter isn't possible to configure due to missing dependencies. Also we can't really be sure that some other things on the page wont remove the page, thus still going to have formatters configure incorrectly (only a lot less likely).

That's why I think that the first solution would be the best option, it's pretty simple to implement, and we can do it as a non breaking API addition.

Remaining tasks

Implement solution (1)

User interface changes

None

API changes

Minor API addition

Data model changes

None

CommentFileSizeAuthor
#15 bad-config.png45.34 KBgoogletorp
#15 select-config.png24.35 KBgoogletorp
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

googletorp created an issue. See original summary.

googletorp’s picture

RainbowArray’s picture

Priority: Normal » Major
Issue summary: View changes
Issue tags: +Usability, +Needs usability review

This seems like a pretty big problem to me.

A site builder can select a field formatter, but there is no error if they don't select the settings for the field formatter before pressing save on manage display. This can lead to big problems when that content is viewed. At best, that field does not display and there is no indication why. At worst, a fatal error.

There should be some sort of prompt or error if field formatter settings are not configured.

swentel’s picture

I'm not to keen (right now) on adding the validation as they'd run on simply saving an entity display every time - or maybe only during config import, but then imports would potentially break on an empty string in the formatter example.

I also think that in most other cases, field formatters are doing a relatively find job because most of them come with default settings, it's just that in the case of the responsive formatter it didn't work out nicely (and I also thing the current patch over there isn't fixing it nicely enough, see comment there), which is why I don't think this is necessarily major.

Bojhan’s picture

Issue tags: -Needs usability review

Nothing to review.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

Thanks for reporting this.

Specific steps to reproduce this through the UI would be helpful, so tagging for an issue summary update with those steps.

xjm’s picture

A novice sprinter could potentially try to reproduce the issue described in the summary and document the results.

Lund’s picture

I am at DrupalCon Dublin2016 and will try reproduce this issue today and write steps on how to replicate it. Im working with mentor @chipway.
https://www.drupal.org/contributor-tasks/add-steps-to-reproduce

Lund’s picture

Issue tags: +Dublin2016

Added Tag to issue.

Lund’s picture

Status: Active » Closed (cannot reproduce)
Related issues: +#2513604: Create default responsive image styles

I havnt been able to reproduce this issue on a clean 8.2.x install.
Steps I did to try and reproduce:

  • Enabled Responsive images module
  • Changed image field formatter on Article content type to responsive image
  • The field configuration is displayed and changed to the formatter default.

I did some digging on some related issues and it seems like there has been some related issues, that i believe might have fixed this issue as well.
I believe these issue are responsible for fixing this issue:

https://www.drupal.org/node/2489162
https://www.drupal.org/node/2513604

googletorp’s picture

Status: Closed (cannot reproduce) » Active

So I tested this:

The root problem is still here: Possible to save malconfigured field display.

On a site with no responsive image styles it's still possible to select responsive style and have it configured in a way that's impossible. What's different from 1 year ago is that reponsive image formatter now gracefully renders the original image instead of creating a fatal error, which is nice.

I still think it's a bug that drupal allows you to configure the field display this way, just because you don't click the little icon and had to validate the form.

It's possible to handle this in the field formatter by providing default values, but I still think Drupal should do better.

Probably not major anymore as core doesn't fatals on this.

@xjm Do you think Drupal should help here, or should we just push this on developers?

swentel’s picture

Priority: Major » Normal

Yeah, not major at all. If there's a problem then this should be handled in picture module imo as well.

googletorp’s picture

Issue summary: View changes
FileSize
24.35 KB
45.34 KB
googletorp’s picture

xjm’s picture

Adding issue credit for triagers at Dublin.

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

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should 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.

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

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

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

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

Version: 8.9.x-dev » 9.3.x-dev
Issue tags: +Bug Smash Initiative

I tested this on Drupal 9.3.x following the steps in the IS and was able to reproduce the problem. I then went and added a responsive image style and then returned to add that to field_image. The new style was not available. I cleared the cache and tried again and still the newly added responsive image style was not available.

Updating version.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Tested with Drupal 10.1.x with the standard profile and can confirm this issue is still there.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.