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:
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
Comment | File | Size | Author |
---|---|---|---|
#15 | bad-config.png | 45.34 KB | googletorp |
#15 | select-config.png | 24.35 KB | googletorp |
Comments
Comment #2
googletorp CreditAttribution: googletorp commentedComment #3
RainbowArrayThis 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.
Comment #4
swentel CreditAttribution: swentel commentedI'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.
Comment #5
Bojhan CreditAttribution: Bojhan as a volunteer commentedNothing to review.
Comment #8
xjmThanks for reporting this.
Specific steps to reproduce this through the UI would be helpful, so tagging for an issue summary update with those steps.
Comment #9
xjmA novice sprinter could potentially try to reproduce the issue described in the summary and document the results.
Comment #10
Lund CreditAttribution: Lund at Adapt commentedI 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
Comment #11
Lund CreditAttribution: Lund commentedAdded Tag to issue.
Comment #12
Lund CreditAttribution: Lund at Adapt commentedI havnt been able to reproduce this issue on a clean 8.2.x install.
Steps I did to try and reproduce:
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
Comment #13
googletorp CreditAttribution: googletorp commentedSo 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?
Comment #14
swentel CreditAttribution: swentel commentedYeah, not major at all. If there's a problem then this should be handled in picture module imo as well.
Comment #15
googletorp CreditAttribution: googletorp commentedComment #16
googletorp CreditAttribution: googletorp commentedComment #17
xjmAdding issue credit for triagers at Dublin.
Comment #24
quietone CreditAttribution: quietone as a volunteer commentedI 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.
Comment #28
smustgrave CreditAttribution: smustgrave at Mobomo commentedTested with Drupal 10.1.x with the standard profile and can confirm this issue is still there.