Jump to:

Problem/Motivation

The logic which decides whether to display the field plugin (formatter/widget) settings edit button currently tests whether there is any settings summary text to display. If so, the summary text and the edit button are displayed.

However, if there is no summary text, the edit button will not be shown, even if settings are available for the plugin. This is a bug; the decision to show the edit-button should depend on whether settings are available.

This matters because hook_field_formatter_settings_form_alter() allows modules to add extra settings to formatters which don't already have settings. Meanwhile, the summary text for the extra settings needs to be set in hook_field_formatter_settings_summary_alter(), but there is no way to guarantee that summary text is being provided by that hook. (Likewise for the widget alter hooks.)

When a contrib module extends a formatter's settings, it doesn't always make sense to add any summary text, because when several modules extend formatter settings, the settings summaries can become overcrowded.

Steps to reproduce this bug

The problem isn't obvious when looking just at core; most (all?) of the core field formatters which have settings produce a summary message in all cases.

To reproduce this, you'll need a module that provides extra field plugin settings. I suggest using Field formatter class, which has a D8 version. It provides an extra setting to all field formatters, to add HTML classes to the display output. If an extra class is specified, it will be indicated in the settings summary message. (I've deliberately disabled the "no class" summary message in the latest 8.x-1.x-dev.)

Proposed Resolution

Refactor Drupal\field_ui\DisplayOverviewBase::buildFieldRow() so that the edit-button is shown whenever there are plugin settings available.

I had a stab at fixing this. The attached patch seems to work okay, lets see if the tests are green.

The patch moves some code which generates the formatter settings form, outside of the if/else block, so that it gets generated whether we are in edit mode or not. Then separate checks are done to determine whether to display the summary and edit button respectivley.

Note that in order to test this, you'll need a module that provides extra field formatter settings. I suggest using the Field formatter class, which has an 8.x version. (I've deliberately disabled the "no class" summary message in the latest 8.x-1.x-dev.)

Not really :-). If the changes here make existing docs incorrect/obsolete, they should be updated accordingly in the patch too.
I.m only talking about checking the existing docs for settingsSummary() and settingsForm() in FormatterInterface because they might mention the current behavior (button only if summary not empty). Maybe they don't and everything's fine, it's just that I'm away from my coding env and checking the issue queues with my phone, so it's not easy for me to check the code myself :-) - but TBH I'd be surprised if the current behavior isn't docimented anywhere.

I was talking yesterday with yched about this issue, and he suggested me to display or not edit plugin link depending on getPluginDefinition() provides plugin settings or not. It works unless hook_field_formatter_settings_form_alter() adds some form elements to a plugin that does not provide settings. In that case, edit plugin link is not displayed and you can't edit settings provided by hook_field_formatter_settings_form_alter().

It works unless
hook_field_formatter_settings_form_alter() adds some form elements to a
plugin that does not provide settings

Currently, a module that implements hook_field_formatter_settings_form_alter() typically also alters the formatter definition to add the corresponding settings - or else the form inputs wouldn't get saved.