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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jmuzz’s picture

Status: Active » Needs review
FileSize
691 bytes
the greenman’s picture

I'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.

jmuzz’s picture

If the custom formatter does have a settings form then $form should get set by the line

eval($formatter->fapi);

so it shouldn't be ignored.