Problem/Motivation
When creating a field with field type "Color Scheme", a warning occurs:
Warning: Undefined array key "default_formatter" in Drupal\Core\Field\FormatterPluginManager->prepareConfiguration() (line 151 of core/lib/Drupal/Core/Field/FormatterPluginManager.php).
The reason is that the field type does not specify the 'default_formatter'.
Background
Drupal core is a bit inconsistent in when it expects this key to be present or not.
In the same class FormatterPluginManager, in one place it calls if (empty($field_type_definition['default_formatter'])) to support the case when the array key is not set. But in another place it just uses the value.
For field types discovery, core actually uses AttributeDiscoveryWithAnnotations which combines annotation discovery and attributes discovery.
For annotations there is also a defaults mechanism in the annotation base class (Drupal\Component\Annotation\Plugin), but if the default value is NULL then it is ignored..
For attributes, the defaults work differently.
We could go down this rabbit hole and open a core issue.
But it is much easier to just add the `default_formatter = NULL` in the annotation.
This is until we actually add a formatter for this field. But I assume the idea is to not display it but only use it internally.
Steps to reproduce
- Enable the color_scheme_field module.
- Go to "Manage fields" section of any paragraph or content type.
- Add a new field, choose "Color scheme" field type.
- Save the field.
Expected: Field is created, now warning.
Actual: Field is created, warning as above.
Proposed resolution
The simple solution is to add the `default_formatter = NULL,` line in the ColorSchemeItem plugin definition.
For tests we have different options:
- Don't add a test for this.
- Add a functional test that follows the steps from above.
- Add a kernel test that calls $formatter_manager->prepareConfiguration('color_scheme_field', []);
Follow-up
In a separate issue we could convert the plugin definition to use an attribute.
We could also open a core issue and discuss whether core should support this key not being set. I think it is not a good use of our time, especially if everything moves to attributes.
Remaining tasks
User interface changes
API changes
Data model changes