FieldType with no available widget causes Fatal error

Yeah, all field types are supposed to have an available widget, if they don't we can't show an input for the default value in the UI.
But we can't break with a fatal if that happens, so I guess the proposed approach seems reasonable.

We'd probably need to check what happens on the "Manage forms" screen if a field has no available widget.

1. +++ b/core/lib/Drupal/Core/Field/FieldItemList.php
   @@ -296,15 +296,17 @@ public function getConstraints() {
   +    // Place the input in a separate place in the submitted values tree.
   

   That comment should really stay next to the line that sets #parents.

2. +++ b/core/lib/Drupal/Core/Field/FieldItemList.php
   @@ -296,15 +296,17 @@ public function getConstraints() {
   +    return ['#markup' => $this->t('No widget available for: %type.', ['%type' => $this->getFieldDefinition()->getDataType()])];
   

   This should go in an "else" for the "if ($widget = ...)" case, we don't want that for the case there is a default_value_callback.

Also, note that this will slightly conflict with #2529034: Replace direct access to FieldConfigBase::default_value with methods. Depending on which gets in first, the other one will need a reroll

Addressed the points which is in #8

Anyone up for reviewing this patch?

I'll review the patch (I'm a novice core contributor.)

By the "Manage forms" screen, you mean the field edit form ?

Reproduced error. Applied patch and tested. The "Manage forms" screen (edit field) looks good (see attached) but received an error in the dblog when on the field edit form, I'm investigating.

Notice: Undefined index: default_widget in Drupal\Core\Field\WidgetPluginManager->prepareConfiguration() (line 154 of /Users/glenshewchuck/Sites/drupal8/htdocs/core/lib/Drupal/Core/Field/WidgetPluginManager.php).

The Manage Form Display shows the field as hidden with no other options available.

Here is the error and backtrace from when I go into the edit field form.

Notice: Undefined index: default_widget in Drupal\Core\Field\WidgetPluginManager->prepareConfiguration() (line 154 of core/lib/Drupal/Core/Field/WidgetPluginManager.php).
Drupal\Core\Field\WidgetPluginManager->prepareConfiguration('example_field_type', Array)
Drupal\Core\Field\WidgetPluginManager->getInstance(Array)
Drupal\Core\Field\FieldItemList->defaultValueWidget(Object)
Drupal\Core\Field\FieldItemList->defaultValuesForm(Array, Object)
Drupal\field_ui\Form\FieldConfigEditForm->form(Array, Object)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
call_user_func_array(Array, Array)
Drupal\Core\Form\FormBuilder->retrieveForm('field_config_edit_form', Object)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}()
call_user_func_array(Object, Array)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1)
Stack\StackedHttpKernel->handle(Object, 1, 1)
Drupal\Core\DrupalKernel->handle(Object)

I'll give that a try.

The ternary fix seems to work.

will look do tomorrow

interdiff

@heddn, nope, that will return either TRUE or NULL, but never $field_type['default_widget']. ?: will cause it to return isset($field_type['default_widget']) when TRUE...

looking at tests

ran out of time

I will take a look at this one

@glenshewchuck #20 :

The Manage Form Display shows the field as hidden with no other options available

(https://www.drupal.org/files/issues/Manage_Form_Display.png)

Thanks for checking that !
There is indeed a slight issue that, in this case, the field should appear in the "Disabled" section at the bottom of the screen (like when you select "- Hidden -" for one of the other fields, it gets moved to the "Disabled" section.

The same problem of the field not being hidden applies to the formatter too in case there's no default_formatter, see interdiff

Thanks @swentel, makes sense. Not sure we need the "else" part though, there should be nothing to remove since we're creating the field anyway. It's rather "only do setComponent() if there is actually a $widget_id" ?

(also, minor, the $options var could be inlined :-)

This is (at least partly) a duplicate of #1864014: Field types specify non-existent default widgets and formatters.

1. +++ b/core/lib/Drupal/Core/Field/FieldItemList.php
   @@ -349,7 +355,7 @@ public static function processDefaultValue($default_value, FieldableEntityInterf
       * @return \Drupal\Core\Field\WidgetInterface
   -   *   A Widget object.
   +   *   A Widget object or NULL if no widget is available.
   

   Then @return must specify null as well.

2. +++ b/core/modules/field_ui/src/Form/EntityDisplayFormBase.php
   @@ -279,6 +279,13 @@ protected function buildFieldRow(FieldDefinitionInterface $field_definition, arr
   +    }
   

   Why do we do this?

3. +++ b/core/tests/Drupal/Tests/Core/Field/FieldItemListTest.php
   @@ -155,4 +156,68 @@ public function testEqualsEmptyItems() {
   +    $field_definition = $this->getMock('DrupalFormStateInterface\Core\Field\FieldDefinitionInterface', ['getType']);
   

   Use PHP 5'5.s ::class constant instead of strings with FQNs.

The patch failed to apply. It output, "error: while searching for:" and then outputs the defaultValueForm public function within FieldItemList.php. I will explain what it looks like is happening to me below. If I've overlooked something while applying the patch, let me know. Thanks.

It looks like the patch is searching for $this->getFieldDefinition()->default_value_callback within the public function defaultValuesForm within /core/lib/Drupal/Core/Field/FieldItemList.php starting on line 297. In my version of core, I have $this->getFieldDefinition()->getDefaultValueCallback().

I re-rolled the patch from #54 to use getDefaultValueCallback() on line 299 of FieldItemList.php

I have rerolled this patch #54 to work with the latest 8.0.x branch. There was a minor edit needed to match a changed method call (see patch for details). The patch applies cleaning and appropriately checks for NULL $widget in FieldItemList and won't try to access it if it is empty, as described in the proposed resolution in the issue summary. The patch also, in the case of NULL $widget, displays 'No widget available....' with #markup.

Minor, can be fixed on commit :

+++ b/core/lib/Drupal/Core/Field/FieldItemList.php
@@ -297,13 +297,17 @@ public function getConstraints() {
+        // Place the input in a separate place in the submitted values tree.
+        $element += $widget->form($this, $element, $form_state);

Nitpick , but that was mentioned in #8 :
This comment explains the line above (the one with #parents). Can we move it one line up ?

Comment moved, committed and pushed to 8.0.x. Thanks!