Quantcast
Channel: Issues for Drupal core
Viewing all articles
Browse latest Browse all 314089

No exception on missing widget or formatter, but a silent fallback

$
0
0

Problem/Motivation

I was trying to find out why the false formatter has been used for a field and it took me pretty long time to find out that the formatter class with the specified ID was already deleted. I would've expected an exception in such cases and not silent fallbacks.

getInstance of both WidgetPluginManager and FormatterPluginManager is retrieving the plugin definition by suppressing the exception on an invalid plugin ID. The fallback mechanism is documented as:

    // Switch back to default formatter if either:
    // - the configuration does not specify a formatter class
    // - the field type is not allowed for the formatter
    // - the formatter is not applicable to the field definition.
    $definition = $this->getDefinition($configuration['type'], FALSE);
    if (!isset($definition['class']) || !in_array($field_type, $definition['field_types']) || !$definition['class']::isApplicable($field_definition)) {

    // Switch back to default widget if either:
    // - the configuration does not specify a widget class
    // - the field type is not allowed for the widget
    // - the widget is not applicable to the field definition.
    $definition = $this->getDefinition($configuration['type'], FALSE);
    if (!isset($definition['class']) || !in_array($field_type, $definition['field_types']) || !$definition['class']::isApplicable($field_definition)) {

As we can see all the checks actually expect a definition array to be returned. However NULL will be returned if there is no plugin for the given plugin ID. This however will trigger silently the fallback mechanism.

If a view or form display have been configured with a specific plugin and suddenly this plugin is missing then an exception should be thrown instead of silently falling back to the default plugin, as otherwise such a misconfiguration might not be detected for a long time.

The change in both plugin managers and at other places has been introduced in #2178795: Allow DiscoveryInterface::getDefinition() to throw an exception for an invalid plugin. We might need follow-ups for other places where an exception should actually be thrown.

Proposed resolution

Do not silently fall back but throw an exception if the specified plugin cannot be found.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet


Viewing all articles
Browse latest Browse all 314089

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>