🇺🇸United States @bleen

+++ b/core/lib/Drupal/Core/Field/Plugin/Field/FieldWidget/StringTextfieldWidget.php
@@ -23,29 +26,29 @@ class StringTextfieldWidget extends WidgetBase {
-    return [
+    return array(
         'size' => 60,
         'placeholder' => '',
-      ] + parent::defaultSettings();
+      ) + parent::defaultSettings();

I'm not sure why the patch is failing to apply, however there was a coding standards change a few months ago (longer?) that says Drupal expects the "[" notation for arrays (see https://www.drupal.org/docs/develop/standards/coding-standards#array → ) so this change (which is where the patch fails) is not correct anyway and should be removed from the patch... the same is true of other array notation regressions throughout the patch.

I'd bet a dollar that if you reroll the patch without those coding style regressions that all would be well with the world

I had a chance to test the patch in #106 and I can confirm that it does address #81/#82 as well as #89.

In addition I was not able to find any other problems when testing with textfields that have unlimited cardinality.

thumbs up from me

Can you please comment on whether the latest patch addresses #81/82 and #89

The patch in #85 has some issues...

First, the "remove" button does nothing at all in the following circumstance:

• Add a text field to a content type with unlimited cardinality
• On the field setting form set the default values to "red" "white" and "blue" and save the field
• Now edit the field
• Notice that the "remove" button added to the default value fields doesn't do anything on that form

Another issue (I'm 99% sure this is realted to #81/#82:

• Add a text field with an unlimited cardinality to a content type
• create a new node with "red" "white" and "blue" as values in that field (save the node)
• Now edit the node.
• Click the remove button next to "blue". You should now have "red" "white" and empty field but instead you have "red" blue" and empty field.

Here testbot... Here boy

I figured out the cause of the issue in #81 though I have no idea what the correct fix might be... Here's the problem:

During the course of processing the form, the FormBuilder->rebuildForm() method is called. It, in turn, eventually calls a stack that looks like this:

If you take a close look at EntityFormDisplay->buildForm() you see this:

public function buildForm(FieldableEntityInterface $entity, array &$form, FormStateInterface $form_state) {
    // ... do some things

    foreach ($this->getComponents() as $name => $options) {
      if ($widget = $this->getRenderer($name)) {
        $items = $entity->get($name);  // <==== HERE"S YOUR PROBLEM
       // .... do more things
      }
    }
    // ... do more things
  }

The problem is that $items gets set based on the cached $entity object without taking into account the changes that have already been made to the form as reflected in $form_state.

A quick-and-hackey fix would be to let this happen and then after the fact, adjust $items based on $form_state , but this seems both wasteful and fragile.

I think this is a core bug regardless and should maybe (probably?) be addressed outside of this issue, but I'm not sure. A LOT of dominos have to fall in just the right way, but this could lead to an editor inadvertently overwriting his/her own data if their site has code to manipulate the entity edit form the way that the functionality in this issue would if it ever gets in.