This is a problem in custom_formatters_field_formatter_settings_form(). The documentation for this hook describes the $form parameter as "The (entire) configuration form array, which will usually have no use here." The function also makes use of a variable called $form and assumes that it won't be set if eval($form->fapi) doesn't do it. By default $form->fapi is set to a blank string, so it does get evaluated and it doesn't set the $form variable. Instead the one that gets passed to custom_formatters_field_formatter_settings_form() gets used. That's wrong because it's a copy of the whole form and the function is supposed to return only the settings for the field. This has been causing problems for me when using the file_entity module because it uses the formatters defined on file fields to allow multiple formatters to be configured for a file type in a display mode.
Specifically:
- The vertical tabs section at the bottom has been getting multiple entries of another custom defined formatter.
- The formatters defined in custom_formatters have a settings section that is a copy of most of the form when it shouldn't even appear in the vertical tabs because it doesn't have settings.
I have a simple patch that fixes the issue.
Comment | File | Size | Author |
---|---|---|---|
#1 | custom_formatters-settings_form_fix-2303543-1.patch | 691 bytes | jmuzz |
file_display_settings_error.png | 43.8 KB | jmuzz |
Comments
Comment #1
jmuzz CreditAttribution: jmuzz commentedComment #2
the greenman CreditAttribution: the greenman commentedI'm not sure this is the right fix, but it does deal with the issue I have experienced.
The $form parameter does seem to be incorrect. Applying this essentially gets the code to ignore the settings form. Which allows me to save formatters. Otherwise, I can make no changes to the formatter display options.
Comment #3
jmuzz CreditAttribution: jmuzz commentedIf the custom formatter does have a settings form then $form should get set by the line
so it shouldn't be ignored.