Steps to repro:

  1. Enable modules field_ui, number and options
  2. Create content type
  3. Add List (text) field and populate required config options
  4. Create node of this content type
  5. View node

The error I saw was:

Drupal\Component\Plugin\Exception\PluginException: The plugin (list_default) did not specify an instance class. in Drupal\Component\Plugin\Factory\DefaultFactory::getPluginClass() (line 62 of /.../core/lib/Drupal/Component/Plugin/Factory/DefaultFactory.php).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dawehner’s picture

Priority: Normal » Critical
Status: Active » Needs review
Issue tags: +Needs tests, +quickfix
FileSize
2.25 KB

The fix is easy, let's also write a test.

dawehner’s picture

FileSize
11.61 KB

Started with a test and realized that you can't use field_view_field to render the output, because of #1977464: The custom field which add for comment con't show in views .

yched’s picture

So, yeah, #1787238: Convert options module formatters to Plugin system changed the formatter plugin ids from 'list_*' to 'options_list_*'.

The old formatter names came from back when list field types were provided by list.module.
- 'list', being a reserved PHP word, was problematic as a module name in D8 (namespace Drupal\list caused fata errors), and #1592632: Merge List field types into Options module moved those field types, and the associated formatters, to options.module - but didn't change machine names / plugin IDs for any of those, leaving them in the "list_*' namespace.
- Then #1787238: Convert options module formatters to Plugin system added the 'options_' prefix, but:
just on formatters names (not on field types),
without the corresponding updgrade path to account for D7 fields still referencing the old formatter names,
witjout updating the 'default_formatter' property on the field types (which causes the bug seen here)

So there are two ways to envision this:
Either we just revert the formatter names to their old 'list_*' names (followup patch in #1787238-31: Convert options module formatters to Plugin system does that - but doesn't have the nice tests the patch here has). Granted, this leaves plugin names that do not follow the recommended pattern of prefixing with the module name, but this has been the case for almost a year now...
Or we settle on the new 'options_' prefix, but then it's more than fixing the 'default formatter' entry like the patch here does:
- we need to do it for the field types as well,
- we need the corresponding upgrade paths :-)

As per the "quickfix" tag, we probably want to go with the former for now - just fix the critical bug recently introduced by #1787238: Convert options module formatters to Plugin system. Cleaning up the non-standard machine names left by #1592632: Merge List field types into Options module is better be done in a separate task, and was definitely out of scope for #1787238: Convert options module formatters to Plugin system.

Attached patch merges the fix from [##1787238-31] and the tests provided here.

dawehner’s picture

FileSize
12.73 KB

Thanks for merging the patches!

Extended the test coverage and fixed the actual render bug in order to make the test pass.

swentel’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: -Needs tests
alexpott’s picture

Status: Reviewed & tested by the community » Fixed

Committed 1ac72a9 and pushed to 8.x. Thanks!

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Added needed modules to reproduce issue