Allow for deletion of a single value of a multiple value field

Feature request :-)

I support this, I have two modules that appear buggy in some configurations because there is no way to remove one of the multiple values added with 'add another item'.
The modules are select_or_other and blockreference. I have given users, in addition to a regular multiselect box, the ability to create multiple drag-and-drop single select lists, which allows them to change the order of the selections.
However when set to 'required' and 'unlimited', there is #1117916: No way to remove added options.
The image shown in #2 by rogueturnip, showing a removal link on the right, is exactly what I've come here to request.

Nice idea. Moving to Drupal 8 where feature requests belong.

Attaching an image from Quick Tabs module which also has a remove button to the right of each instance.

I made that jQuery idea already, rogueturnip

but if you hit the add another value button, the deleted one returns :p

I will improve the jquery code to watch the button and delete the line again

Subscribe. Linking to #196421-249: Deleting unwanted multiple values / multiple values delta issues for reference.

#8 is a second feature request on top of this one.

There was a similar debate for the CCK D6 multigroup feature.
What got implemented over there (done in parallel and independently of the D7 Field API work) was a "delete" button that let you "hide / fold" the corresponding row (or "unhide / unfold" it).

Subscribing... This is much needed.

Subscribing!

subscribing

sub

Yes Sub!

sub

I've solved this in probably a very unsexy manner, but it works.

I've got a multiple field in a content type called TYPE. The field is called 'field_extrafield' and is a term reference field in my case.

Create a module called HOOK with this function:

function HOOK_node_validate($node, $form, &$form_state) {
  if ($node->form_id == 'TYPE_node_form') {
    foreach ($node->field_extrafield['und'] as $mkey => $mvalue) {
      if (is_array($mvalue)) {
        if (!isset($mvalue['tid'])) {
          form_set_value($form['field_extrafield']['und'][$mkey], NULL, $form_state);
        }
      }
    }
  }
}

This might not work out of the box. Mu case inparticular involves field collections so the arrays look different, but this should get you going.

This function add custom validation to the form after it is submitted. The first IF assures you you're working on the correct form. Then we're checking if a value has been set in the multiple field. The fields will be listed as numbered arrays under ['field_name']['und'], but there will also be string items here, so you need to check that you're working on items that are arrays (is_array). Since this is a term ref in my case, I'm checking to see if the array under ['und'] has the ['tid'] set. If not, I set the whole array to NULL using the form_set_value function. This is the only way to write changes to the form inside the validation function.

This feels like a very brutal way of doing it... setting fields to NULL in the validation form... any other suggestions?

subscribe

1) It would probably be better to unset the field rather than set it to NULL.

2) In views, you can rearrange the fields you've selected, but also delete them. MerlinofChaos has got this figured out. I suggest looking at his code for inspiration. I won't have time myself for a couple of weeks.

+1 for a Drupal 7 solution for this. Is #19 in the running? Anyone else use it successfully?

Drupal 7 custom solution.

I just posted in another thread my custom module that can create a remove button for selected 'unlimited' fields in Drupal 7.

http://drupal.org/node/1143880#comment-5198566

Will this work with image/file fields? Will the files get deleted or will there be dangling "fid's"?

To my knowledge image and file fields have their own Remove button in D7. I specifically added a configuration page to this module where you select which fields to apply the new Remove button in order to prevent complications with fields that already have this functionality.

I just tested Image and File fields on my D7 site, and they do already have a Remove button.

But to answer your question, no this module does not remove or delete any files or images. I've looked into how the File field removes fields using legitimate drupal ajax, and plan to contribute a module that does this correctly, but have not had the time to implement it yet.

Also, I found a tiny bug in the module and have fixed it. Everything should be working fine now.
Here is a link to my blog post where you can download the module:
http://websmiths.co/blog/drupal-7-unlimited-fields-remove-button

Any suggestions are appreciated.

edit: changed link to go to blog post, so I don't have to find all these links and change them after every update.

Thanks for the custom module daggerhart!

Unfortunately it's not working for me :( . I have an unlimited node_reference field (references project), and it shows up on your module's admin page, but checking it doesn't change anything when I go to edit a node that uses that field... no remove item.

Hi davidlerin,

I've updated the module to work with date fields, node & user references. The link above now goes to the updated module, but here it is again in case there is some sort of trouble.

v0.3
http://websmiths.co/sites/default/files/projects/unlimitedfield_remove-7...

Is this an issue anymore with merlinofchaos's patch?
http://drupal.org/node/1234574#comment-5232728

If I understand it correctly, his patch applies to the field collections module. This issue is about core functionality of a remove/delete button for any type of field. Am I mistaken in this?

@daggerhart: #29 is correct.

To that end, any chance you can put your D7 contrib module here on drupal.org (even if it's just a sandbox project for now) so that discussion and support of your custom solution can continue in a more appropriate channel and we can leave this issue for solving this problem in D8 core?

Thanks!
-Derek

@dww,

Absolutely.

I have created the sandbox project for this functionality as a D7 module here:
http://drupal.org/sandbox/daggerhart/1363702

Sorry to hijack the thread.
Thanks,
- Jonathan

@daggerhart just downloaded your sandbox (version 7.x-0.3)

Thanks so much for posting this online and it's a great solution to an infuriating problem in D7. Should be in Core IMHO.

Thanks again - very grateful.

Rob

Tagging.

Just checked out and used daggerhart's module. Worked perfectly. Thank you!

daggerhart++

@daggerhart - works perfectly!! Thanks for the save :)

The 'UnlimitedField Remove' module works great, but not for link fields. On link fields, the button doesn't appear at all.

Use-case: If the link field title is mandatory, I can't remove it at all (which is why I needed the 'remove' feature on the 1st place). By making the title optional, I can delete it in the usuall, non-intuitive D7 method, by simply deleting the text inside the field. But then I can't make it mandatory.

Ref: http://drupal.org/node/1616310

@daggerhart - works very well even inside field_collection with my custom multi-value field. There is just one niggle I found when testing it out...

If you have a field_collection set to cardinality -1 and you remove a field_collection container item with its Remove button then the remove button provided by module ceases to work until refresh.

Despite this little niggle and very specific use case, it works a treat and saved me a heap of time! Thank-you!

Has anyone attempted this solution with Addressfield? Currently on node save, it adds the empty Addressfield and plots a point in the middle of the US in addition to the address submitted.

Marked #1120162: Add "delete" links to multivalue field values as duplicate. Assigning to myself, going to try this during the weekend.

Ok, this is too crazy to get it right before 1 december.

swentel, apparently there is more time to get this done:
http://buytaert.net/drupal-8-feature-freeze-extended

Yeah, but I'm not sure whether I have time enough for an initial patch before 1 december to get it going enough :)

Is it still a feature request or can we convert it to task? It is very basic functionality missing form core so IMO we can change it to task.

Just confirmed with @swentel on IRC he also thinks it is a difficult task.

This will be D9 material I'm afraid unless someone gets on this.

Well .. given it's a normal priority task .. it wouldn't hurt in the 8.x queue for now?

FWIW, +1 to this fix, good day you all! :)

EDIT: oops, didn't mean to change version state, leaving it now, but please swentel or any other, adjust it as you see best.

Subscribing and adding that yes, this is a bit of a tricky problem to solve. There are few fields that implement a remove button (e.g. File/image fields and a few other custom fields), and it's hard (and annoying) to build in a 'Remove' button on custom multi-value fields, but it would be a huge UX win if we had this out of the box for multi-value fields.

I'm coming over from #2035753: Add 'remove item' function to multi-value autocomplete widget.

Note also that there's a contrib module that does what would be nice to do in core for multi-value fields: Multiple Fields Remove Button

However, Multiple Fields Remove Button does NOT support all modules / widgets, each needs to be separately programmed.

Hopefully, Remove button is added to all multivalue fields in core for all modules / widgets

Hi,

I found a solution, with reference to #2287803: Make this work with all fields by default, apply Patch #4 on multiple_fields_remove_button-7.x-1.4.zip shall work with all modules and widgets.

Please take note that multiple_fields_remove_button-7.x-1.5.zip does NOT have the patch #4 committed, also not patchable with patch #4, already reported to the maintainer.

Drupal 8 shall make this in core coz it's ridiculous without a Remove button for Multivalue fields since day one.

Thanks

Will not happen in 8.0.x-dev since it's not critical.

Hi,

It's Absolutely Critical if your page has multivalue Field Collection, File, Image fields which already provided Remove button, the whole page will become Very Messy and NOT Standardized if some multivalue fields have Remove button while others do not.

Remove button shall be made in core so as to provide a user-friendly, clean and standardized interface. #2287803: Make this work with all fields by default

Thanks

@paulwdru, I think @ARtusamak meant that it is not Critical based on the Priority levels of issues and because of that cannot go into 8.0.x since it does not qualify as an allowed change for patch releases. It looks like there is still a little time to get this in to 8.1.x, so a patch would be helpful.

it's not working with editable display formatter so you won't clear the value through ajax save.

As always, great software needs a "working" UI or it's just for small group of geeks.

@jusfeel,

Drupal is always meant for Geeks, powerful & highly flexible, I love it.

The only drawbacks of Drupal are confusing / unorganized / inconsistent User-Interface, not nicely touched up in the perspective of end users' experiences.

Added to summary:

Note: For 7.x there is a contrib module for that: https://www.drupal.org/project/multiple_fields_remove_button
This issue is about adding that functionality to core.

I created a working remove item button in a custom field widget using the following code:

  /**
   * {@inheritdoc}
   */
  protected function formMultipleElements(FieldItemListInterface $items, array &$form, FormStateInterface $form_state) {
    $elements = parent::formMultipleElements($items,$form,$form_state);
    $field_name = $this->fieldDefinition->getName();
    $parents = $form['#parents'];

    foreach (Element::children($elements) as $element_key) {
      if (is_int($element_key)) {
        $delta = $element_key;

        $wrapper_array = array_merge($parents, [
          $field_name,
          $delta,
          'remove',
          'item'
        ]);
        $wrapper_id = Html::getUniqueId(implode('-', $wrapper_array));
        $elements[$delta]['#prefix'] = "<div id={$wrapper_id}>";
        $elements[$delta]['#suffix'] = '</div>';
        $elements[$delta]['remove_item'] = [
          '#type' => 'submit',
          '#value' => $this->t('Remove item'),
          '#submit' => [[$this, 'removeItemSubmit']],
          '#ajax' => [
            'callback' => [$this, 'removeItemAjax'],
            'wrapper' => $wrapper_id,
            'effect' => 'fade',
          ],
          '#name' => implode('_', $wrapper_array),
          '#attributes' => ['class' => ['field-remove-item-submit']],
          '#limit_validation_errors' => [array_merge($parents, [$field_name])],
        ];
      }
    }


    return $elements;
  }

  public function removeItemSubmit(array $form, FormStateInterface $form_state) {
    $button = $form_state->getTriggeringElement();

    // Go one level up in the form, to the widgets container.
    $element = NestedArray::getValue($form, array_slice($button['#array_parents'], 0, -1));
    $container_element = NestedArray::getValue($form, array_slice($button['#array_parents'], 0, -2));
    $field_name = $this->fieldDefinition->getName();
    $field_parents = $element['#field_parents'];
    $delta = $element['#delta'];
    $field_values = &$form_state->getValue($container_element['#parents']);
    unset($field_values[$delta]);

    // Increment the items count.
    $field_state = static::getWidgetState($field_parents, $field_name, $form_state);
    $field_state['items_count']--;
    static::setWidgetState($field_parents, $field_name, $form_state, $field_state);

    $form_state->setRebuild();
  }

  public function removeItemAjax(array $form, FormStateInterface $form_state) {
    return [
      '#type' => 'hidden',
      '#attributes' => [
        'data-description' => 'It is a requirement to return something to make an ajax call hide the entire element.'
      ]
    ];
  }

Cool! so needs-review...

@Eyal Shalev file is present but your patch didn't applied, let me try this patch.
If it gives the same result then i think bot Test has some issues, we need to work on them too.

This would be easier to review if the (totally sensible) code style changes were not in it.

I tried to replace all the [] arrays to array(). This was done manually so it could fail.

Marking as Needs Review for #63 patch.

Code looks good, but seems to need a rebase.

I could apply the patch, so no reroll/rebase is needed.

See the testbot in #65:

8.1.x: PHP 5.5 & MySQL 5.5 Patch failed to apply

@alex.rutz, Yes #65 patch failed to apply and bot test too. I was talking about #63.

I've found some bugs with the first patch.

The changes are:

• The ajax callback no longer return an empty element but the whole container.
• The id_prefix and wrapper_id variables are moved up in the formMultipleElements method.
• The submit method will now affect both the form_state values and the form_state user_input.
• The submit method will now only unset the choosen item but move all the items after it one delta lower.

• Fixed the cause of the test fail.
• Only add the remove button when the field cardinality is unlimited and it is not programmed.

Same as #74. I didn't patch against 8.1.x

Tested, works for me.
One comment:
Removing the last item removes the "Add another item" button too (because the whole wrapper is re-generated by ajax with no item).
My solution:
added checking:
$field_state['items_count'] > 0
to avoid deletion (displaying the remove button) when only one item is left.

Re-test passed.

This is not working in autocomplete term fields, i get an ajax-http Error!

I am having an issue related to removing single items from a list on an edit form, both before and after installing patch #77. I'm wondering if anyone has had a similar issue. It happens when I do the following:

1) Create a list of 3 items (A, B, and C) and save the list.

2) Open the list for editing. As expected, the list appears on the edit form like this:
1. A
2. B
3. C
4.

3) Remove item A and then item B. The list now appears like this, as it should:
1. C
2.

4) Click the button to add another item to the list.

The expected result is this list:
1. C
2.
3.

However, the actual result is this:
1. C
2.
3. C

The new item comes pre-populated with the item that was in that slot at the start, rather than an additional empty slot as expected. Any ideas on the cause/or solution to this would be extremely helpful. Thanks!

Edit: You can reproduce this behavior on simplytest.me with a clean Drupal 8.1.8 install. Just add a new field to an article content type with unlimited values and follow the steps above and you'll see the same result.

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.

#77 patch working my fine except comment #80.

Regarding #80 prepare a patch. Please review it.

Patch again.

Here testbot... Here boy

One problem with this patch is that the removeItemSubmit public function added by this patch is incompatible with the same function name used in the entity_browser module (entity_browser/src/Plugin/Field/FieldWidget/EntityReferenceBrowserWidget.php)

I suggest using a different name here so it doesn't break existing sites.

Or, if entity_browser needs to update it's argument list, let me know and I'll submit that as an issue for them, but wasn't sure they would care about a conflict with a patch that hasn't been committed yet.

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.

I was working on this issue these days, and this is one widget working for my string text field. It uses some code from field_collection module, adds a few customization. Maybe someone can get some idea for your customization.

namespace Drupal\bix_global\Plugin\Field\FieldWidget;

use Drupal\Component\Utility\Html;
use Drupal\Core\Field\FieldItemListInterface;
use Drupal\Core\Form\FormStateInterface;
use Drupal\Core\Field\Plugin\Field\FieldWidget\StringTextfieldWidget;
use Drupal\Component\Utility\NestedArray;
use Drupal\Core\Field\FieldStorageDefinitionInterface;

/**
 * Plugin implementation of the custom string widget.
 *
 * @FieldWidget(
 *   id = "bix_global_string_textfield",
 *   label = @Translation("BIX Global Textfield"),
 *   field_types = {
 *     "string"
 *   },
 * )
 */
class BixGlobalStringTextfieldWidget extends StringTextfieldWidget {

  /**
   * {@inheritdoc}
   */
  public function formElement(FieldItemListInterface $items, $delta, array $element, array &$form, FormStateInterface $form_state) {
    $element = parent::formElement($items, $delta, $element, $form, $form_state);


    $field_name = $this->fieldDefinition->getName();

    // Nest the field collection item entity form in a dedicated parent space,
    // by appending [field_name, delta] to the current parent space.
    // That way the form values of the field collection item are separated.
    $parents = array_merge($element['#field_parents'], [$field_name, $delta]);
    //$parents = $form['#parents'];
    $element += [
      //'#element_validate' => [[static::class, 'validate']],
      '#parents' => $parents,
      '#field_name' => $field_name,
    ];

    // Put the remove button on unlimited cardinality field collection fields.
    if ($this->fieldDefinition->getFieldStorageDefinition()->getCardinality() == FieldStorageDefinitionInterface::CARDINALITY_UNLIMITED) {
      $options = ['query' => ['element_parents' => implode('/', $element['#parents'])]];
      $element['actions'] = [
        '#type' => 'actions',
        'remove_button' => [
          '#delta' => $delta,
          '#name' => implode('_', $parents) . '_remove_button',
          '#type' => 'submit',
          '#value' => t('Remove'),
          '#validate' => [],
          '#submit' => [[static::class, 'removeSubmit']],
          '#limit_validation_errors' => [],
          '#attributes' => array(
            'class' => array('bix-global-custom-multi-field-remove-button'),
          ),
          '#ajax' => [
            'callback' => [$this, 'ajaxRemove'],
            'options' => $options,
            'effect' => 'fade',
            'wrapper' => $form['#wrapper_id'],
          ],
          '#weight' => 1000,
        ],
      ];
    }
    return $element;
  }

  /**
   * {@inheritdoc}
   */
  protected function formMultipleElements(FieldItemListInterface $items, array &$form, FormStateInterface $form_state) {
    // We don't want to render empty items on field collection fields
    // unless a) the field collection is empty ; b) the form is rebuilding,
    // which means that the user clicked on "Add another item"; or
    // c) we are creating a new entity.
    if ((count($items) > 0) && !$form_state->isRebuilding() && !$items->getEntity()->isNew()) {
      $field_name = $this->fieldDefinition->getName();
      $cardinality = $this->fieldDefinition->getFieldStorageDefinition()->getCardinality();
      $parents = $form['#parents'];
      if ($cardinality == FieldStorageDefinitionInterface::CARDINALITY_UNLIMITED) {
        $field_state = static::getWidgetState($parents, $field_name, $form_state);
        $field_state['items_count']--;
        static::setWidgetState($parents, $field_name, $form_state, $field_state);
      }
    }

    // Adjust wrapper identifiers as they are shared between parents and
    // children in nested field collections.
    $form['#wrapper_id'] = Html::getUniqueID($items->getName());
    $elements = parent::formMultipleElements($items, $form, $form_state);
    $elements['#prefix'] = '<div id="' . $form['#wrapper_id'] . '">';
    $elements['#suffix'] = '</div>';
    $elements['add_more']['#ajax']['wrapper'] = $form['#wrapper_id'];
    return $elements;
  }

  /**
   * Submit callback to remove an item from the field UI multiple wrapper.
   *
   * When a remove button is submitted, we need to find the item that it
   * referenced and delete it. Since field UI has the deltas as a straight
   * unbroken array key, we have to renumber everything down. Since we do this
   * we *also* need to move all the deltas around in the $form_state->values
   * and $form_state input so that user changed values follow. This is a bit
   * of a complicated process.
   */
  public static function removeSubmit($form, FormStateInterface $form_state) {
    $button = $form_state->getTriggeringElement();
    $delta = $button['#delta'];

    // Where in the form we'll find the parent element.
    $address = array_slice($button['#array_parents'], 0, -4);
    $address_state = array_slice($button['#parents'], 0, -3);

    // Go one level up in the form, to the widgets container.
    $parent_element = NestedArray::getValue($form, array_merge($address, ['widget']));

    $field_name = $parent_element['#field_name'];
    $parents = $parent_element['#field_parents'];

    $field_state = static::getWidgetState($parents, $field_name, $form_state);

    // Go ahead and renumber everything from our delta to the last
    // item down one. This will overwrite the item being removed.
    for ($i = $delta; $i <= $field_state['items_count']; $i++) {
      $old_element_address = array_merge($address, ['widget', $i + 1]);
      $old_element_state_address = array_merge($address_state, [$i + 1]);
      $new_element_state_address = array_merge($address_state, [$i]);

      $moving_element = NestedArray::getValue($form, $old_element_address);

      $moving_element_value = NestedArray::getValue($form_state->getValues(), $old_element_state_address);

      $moving_element_input = NestedArray::getValue($form_state->getUserInput(), $old_element_state_address);

      // Tell the element where it's being moved to.
      $moving_element['#parents'] = $new_element_state_address;

      // Move the element around.
      $form_state->setValueForElement($moving_element, $moving_element_value);
      $user_input = $form_state->getUserInput();
      NestedArray::setValue($user_input, $moving_element['#parents'], $moving_element_input);
      $form_state->setUserInput($user_input);

      // Move the entity in our saved state.
      if (isset($field_state['entity'][$i + 1])) {
        $field_state['entity'][$i] = $field_state['entity'][$i + 1];
      }
      else {
        unset($field_state['entity'][$i]);
      }
    }

    // Then remove the last item. But we must not go negative.
    if ($field_state['items_count'] > 0) {
      $field_state['items_count']--;
    }
    else {
      $form_state->setValue('empty_item', 1);
    }

    // Fix the weights. Field UI lets the weights be in a range of
    // (-1 * item_count) to (item_count). This means that when we remove one,
    // the range shrinks; weights outside of that range then get set to
    // the first item in the select by the browser, floating them to the top.
    // We use a brute force method because we lost weights on both ends
    // and if the user has moved things around, we have to cascade because
    // if I have items weight weights 3 and 4, and I change 4 to 3 but leave
    // the 3, the order of the two 3s now is undefined and may not match what
    // the user had selected.
    $input = NestedArray::getValue($form_state->getUserInput(), $address_state);
    // Sort by weight.
    // This sort function depends on field_collection module.
    uasort($input, '_field_collection_sort_items_helper');

    // Reweight everything in the correct order.
    $weight = -1 * $field_state['items_count'];
    foreach ($input as $key => $item) {
      if ($item) {
        $input[$key]['_weight'] = $weight++;
      }
    }

    $user_input = $form_state->getUserInput();
    NestedArray::setValue($user_input, $address_state, $input);
    $form_state->setUserInput($user_input);

    static::setWidgetState($parents, $field_name, $form_state, $field_state);

    $form_state->setRebuild();
  }

  /**
   * Ajax callback to remove a field collection from a multi-valued field.
   *
   * @param array $form
   * @param \Drupal\Core\Form\FormStateInterface $form_state
   *
   * @return \Drupal\Core\Ajax\AjaxResponse
   *   An AjaxResponse object.
   *
   * @see self::removeSubmit()
   */
  function ajaxRemove(array $form, FormStateInterface &$form_state) {
    // At this point, $this->removeSubmit() removed the element so we just need
    // to return the parent element.
    $button = $form_state->getTriggeringElement();
    $element = NestedArray::getValue($form, array_slice($button['#array_parents'], 0, -3));
    $delta = $element['#max_delta'];

    if ($delta === 0) {
      $empty_item_flag = $form_state->getValue('empty_item');
      // Reset the last item's value to be NULL.
      if ($empty_item_flag) {
        $element[$delta]['value']['#value'] = '';
      }
    }
    return $element;
  }

  /**
   * {@inheritdoc}
   */
  public static function addMoreSubmit(array $form, FormStateInterface $form_state) {
    $button = $form_state->getTriggeringElement();

    // Go one level up in the form, to the widgets container.
    $element = NestedArray::getValue($form, array_slice($button['#array_parents'], 0, -1));
    $field_name = $element['#field_name'];
    $parents = $element['#field_parents'];

    // Increment the items count.
    $field_state = static::getWidgetState($parents, $field_name, $form_state);
    $field_state['items_count']++;

    static::setWidgetState($parents, $field_name, $form_state, $field_state);

    $form_state->setRebuild();
  }

  /**
   * {@inheritdoc}
   */
  public static function addMoreAjax(array $form, FormStateInterface $form_state) {
    $element = parent::addMoreAjax($form, $form_state);

    // Set the newest item empty value.
    $delta = $element['#max_delta'];
    $element[$delta]['value']['#default_value'] = '';
    $element[$delta]['value']['#value'] = '';

    return $element;
  }
}

smiletrl: rather than pasting a huge amount of text like that, it would probably be better to upload it as an actual file.

bleen: I can confirm both of the issues you reported, so agree this needs more work.

How about something simpler ?
Adding column and a checkbox, that is used in WidgetBase::extractFormValues() to filter out unwanted values.
The advantage is that it avoids AJAX callbacks, also you can change your mind and just un-check.
Could also add JS/behavior for it that hides the checkboxes and adds buttons in their place (that just toggle the hidden checkboxes).

+++ b/core/lib/Drupal/Core/Field/WidgetBase.php
@@ -353,6 +369,11 @@ public function extractFormValues(FieldItemListInterface $items, array $form, Fo
+        // Filter out removed items

Comments should (noramlly) begin with a capital letter and end with a full stop / period .

+++ b/core/lib/Drupal/Core/Field/WidgetBase.php
@@ -202,6 +202,22 @@ protected function formMultipleElements(FieldItemListInterface $items, array &$f
+          $element['_remove'] = array(
+            '#title' => $this->t('Remove'),
+            '#title_display' => 'invisible',
+            '#type' => 'checkbox',
+            '#default_value' => $items[$delta]->_remove ?: FALSE,
+            '#weight' => 101,
+          );

use short array syntax (new coding standard).

Hm. Don't know if I'm mistaken but patch #97 seems to add the checkbox to every field - no matter whether it actually consists of multiple values (cardinality!=1) or not.

@rgpublic: it is added inside if ($is_multiple) {...} right beside '_weight' so it really shouldn't

Ah, thanks @tacituseu. See it now. Did a mistake while adapting the patch to 8.2. It seems to work now. I've attached it in case anyone needs this.

Adds class 'removed' to the row so it could be themed or just "display: none"d.

Missed .once() in behavior, converted to button triggered to be consistent with field and image widgets.

Re-roll of patch from #105 for 8.2.x

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

@bleen: yes the alternative approach solves all of them by not messing with $form_state over AJAX.

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

The patch from 106 is hard to scan with the unrelated coding standards updates .. can we leave those out please. Also, we definitiely need for tests for this.

Also needs work for fields with fixed (>1) cardinality, and no-js graceful degradation.

Re-rolled patch from #106, removed coding standards updates and added a check of field items to only apply the remove button when the field is not a new/blank field item.

No-js graceful degradation and coding standard fixes from #112, left out "apply the remove button when the field is not a new/blank field item" as it forces you to "Add another item" to be able to delete last one, it makes sense in file/image widgets due to their nature but not on generic fields in my opinion.
Still no tests,

Minor CSS cleanup, swapping order of button and checkbox to get styles consistent with file/image widget.

Adding a fix to #112 to solve a double binding issue

Fixing patch

Test for last patch

Could you please stop this nonsense of rolling for 8.3.x/8.2.x ?
It is just pointless noise, there is no way this gets into 8.3.x.

@tacituseu: But you forget that this might be very helpful for people who currently cannot upgrade and need this.

@rgpublic: I didn't, frankly they shouldn't use it on production, it's a hard problem, the issue was created in 2011 and is slow enough even without it, the proposed approach doesn't even have blessing of the system maintainers yet.

What would be very helpful is tests ;) they would be useful even if approach changes.

I tested the 8.4.x patch on a vanilla install of drupal 8.4.x dev, with the paragraphs and field_group module installed. If you create a field group add a entity reference paragraphs inside the group and give that a default paragraph, you will end up with this error:

in the code, the error is originating from the code $remove_element = $item['_remove']; as the default paragraph doesn't have a value for $item['_remove'] and so it comes over as null.

Here's how I had the paragraph setup in the content type:

@samuel.seide: Thanks for testing, it happens because the code assumes (wrongly) that each field extending WidgetBase and overwriting ::formMultipleElements() will call parent::formMultipleElements(), but Paragraphs doesn't.
I will post an updated patch in a couple of days.

I'm not familiar with Paragraphs, is your expectation it will somehow 'work' with it, or just not break ?

My expectation is that the patch should have some checking in it so that if the $item['_remove'] is not available then it won't run that code. Basically the patch should be able to function without it throwing up notices when a default paragraph is being used.

Adding the patch for removing the single item in the multiple text field values.
It is working fine in 8.3.3 branch

Please review

@samuel.seide: Here it is, also updated for ES6.

There's still some JS double-click issue when used within Paragraphs.
Edit: Caused by nested '.field-multiple-table' tables.

Should be fixed now.

@MRPRAVIN Your patch contains a custom module in it - modules/custom/rb_account_profile/rb_account_profile.module b/modules/custom/rb_account_profile/rb_account_profile.module so there's no way to test it...

Here is a patch that should work for 8.3.5. See 1038316-131-field-multiple-remove-item-alt.patch if you're running 8.4.x

@ samuel.seide Thanks for pointing one. I have updated the patch file now. Please test and let us know. May be this patch will be helpful :)

Here i have attached the patch after @samuel.seide comments reviewed. Please test this patch. I think it will help to someone in Drupal World :) It's works fine in 8.3 Drupal version. Need suggestions also please review.

Backport policy, also Automated patch testing.

@here Can someone point out me please why patch gets failed? Based on suggestions i'll work on it.

+++ 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

@bleen, Thank you for point out me :) Notation for arrays are changed in coding standards. you are correct.

rerolled against 8.4.x for my own use

Re-roll of #131 after #2898261: In jQuery 3, $('#') throws syntax errors

There seems to be two competing approaches contending in this issue. #143 is with ajax and #145 is with checkboxes. Can we get an IS update and proposed resolution? The issue description is fine, but I don't see what/how we want to fix this agreed upon yet. That makes it really hard to review and provide feedback on patches, because I don't know which is the preferred approach. I only read back through the last 75 or so comments for the past year, and there wasn't any real sense on what has been decided. Can we decide on that before throwing more patches against this thing?

@heddn: #85 is the last
comprehensive patch on the AJAX path, but as mentioned in #89 it has some problems.

There's a lot of noise - people learning how to make patches, incomplete solutions, re-rolls for obsolete versions, #143 is just a last of "works for my limited use-case" patches (only textfield - started in #128).

So, one issue with #143 is that it only supports text fields. And the approach won't scale very well to non-text fields. Meaning, what is built there won't shoehorn into any other field types. So... back to the drawing board?

I spent a fair amount of time banging away at this today. I figured out one thing here close the end of the day... we won't be able to do this without a some changes to field widget base. The latest non JS patch in #143 was done entirely on the sub widget. That doesn't work if you have ajax refreshing in the field. Which I have on my custom field. I'll have to changes some things up in the widget base. Because that's where the item_count is getting calculated and used in formMultipleElements(). In the $max variable.

No patch, because I don't have any code. Just lots of time spent in xdebug trying to figure out this special edge case.

Here's a patch (it doesn't work yet). It doesn't seem to be removing the items. But, its moderate progress as we now are moved up to the base class. So all field types will eventually get this functionality.

Here's a new patch that seems to work in all cases for my address field. It hasn't been extensively tested, but at least it seems to be functional. Sorry about the interdiff; I don't think it is very readable.

OK, this is a proper interdiff for 152.

Here's what it looks like fully loaded with several values/locations:

I've added a generous number of example locations on the page. I can remove any one of them or add another one.

When the page first loads with no values/locations, it looks like the following:

One must click add to add the first value/location.

Based on some feedback from @alexpott in slack, I've improved the button language to read, "Add item" or "Add another item" depending on if this is the initial item or not.

Also, flagging for usability review.

Reviewing #152.

1. +++ b/core/lib/Drupal/Core/Field/WidgetBase.php
   @@ -208,36 +208,64 @@ protected function formMultipleElements(FieldItemListInterface $items, array &$f
   +      $wrapper_id = Html::getUniqueId($id_prefix . '-add-more-wrapper');
   

   The wrapper is being used for more than adding more. It is also being used for removing.

2. +++ b/core/lib/Drupal/Core/Field/WidgetBase.php
   @@ -208,36 +208,64 @@ protected function formMultipleElements(FieldItemListInterface $items, array &$f
   +      foreach ($elements as $element) {
   +        $elements['#prefix'] = '<div id="' . $form['#wrapper_id'] . '">';
            $elements['#suffix'] = '</div>';
   +        $elements['add_more']['#ajax']['wrapper'] = $form['#wrapper_id'];
   +      }
   

   This looks completely unnecessary.

3. +++ b/core/lib/Drupal/Core/Field/WidgetBase.php
   @@ -208,36 +208,64 @@ protected function formMultipleElements(FieldItemListInterface $items, array &$f
   +        '#value' => t('Add another item'),
   

   Could do something like '#value' => $delta > 0 ? t('Add another item') : t('Add item'),
   Not adding an item by default makes required fields in the single widget form work really nicely.

4. +++ b/core/lib/Drupal/Core/Field/WidgetBase.php
   @@ -208,36 +208,64 @@ protected function formMultipleElements(FieldItemListInterface $items, array &$f
   +        '#limit_validation_errors' => [array_merge($parents, [$field_name])],
   

   I'd have this set to [] because clicking add more shouldn't validate the exist elements imo.

Also thinking about this some more I thing the remove thing should be optional - or maybe a whole new WidgetBase so existing code and alters still work as expected.

+++ b/core/lib/Drupal/Core/Field/WidgetBase.php
@@ -208,36 +208,63 @@ protected function formMultipleElements(FieldItemListInterface $items, array &$f
+      $form['#wrapper_id'] = $wrapper_id;
...
+              'wrapper' => $form['#wrapper_id'],

I don't think we need $form['#wrapper_id'].

+++ b/core/lib/Drupal/Core/Field/WidgetBase.php
@@ -208,36 +208,63 @@ protected function formMultipleElements(FieldItemListInterface $items, array &$f
+      $id_prefix = implode('-', array_merge($parents, [$field_name]));
+      $wrapper_id = Html::getUniqueId($id_prefix . '-add-wrapper');

I'm wondering in general why it uses a *unique* ID. ajax IDs actually shouldn't be unique because the ajax systems relies on theming being not. For example, it automatically prepends messages to the replaced element. That only works if the ID does not change after the initial replacement happened as otherwise the second ajax command won't be able to prepend before the old ID.

I changed the paragraphs widget recently to a non-unique ID in #2939718: Remove validation of closed paragraphs, fix validation and display of validation message for collapse and it worked fine. Probably the only exception to that would be if you'd have multiple entity forms on the same page but I don't think that is supported, at least not for the same entity type.

I guess it doesn't matter that much for core as both add and remove ignore validation errors and are not expected to have any messages.

+++ b/core/lib/Drupal/Core/Field/WidgetBase.php
@@ -208,36 +208,63 @@ protected function formMultipleElements(FieldItemListInterface $items, array &$f
+      for ($delta = 0; $delta <= $max; $delta++) {
+        $elements[$delta]['actions'] = [
+          '#type' => 'actions',
+          'remove_button' => [
+            '#delta' => $delta,
+            '#name' => implode('_', array_merge($elements[$delta]['#field_parents'], [$field_name, $delta])) . '_remove_button',
+            '#type' => 'submit',
+            '#value' => t('Remove'),
+            '#validate' => [],
+            '#submit' => [[$this, 'ajaxSubmitRemove']],
+            '#limit_validation_errors' => [],
+            '#attributes' => [
+              'class' => ['remove-field-delta--' . $delta],
+            ],
+            '#ajax' => [
+              'callback' => [$this, 'removeAjaxContentRefresh'],
+              'effect' => 'fade',
+              'wrapper' => $form['#wrapper_id'],
+            ],
           ],

If we move the wrapper ID creation to before the loop where we create each single item form we could put this in there and do less looping.

And from that I guess... consensus has been reached, before another patch was thrown ? ;)

re #165: not necessarily, but the use of form_state and #ajax does seem to be functional. And its a design paradigm that seems to resonate with a lot of Drupal users.

Ignore the patch in #158. It was overly ambitious. Here's a re-worked on top of #152 and addresses most of the feedback since then. The only thing I haven't touched is how to make it toggleable as suggested in #161.

Re #163

I'm wondering in general why it uses a *unique* ID. ajax IDs actually shouldn't be unique because the ajax systems relies on theming being not. For example, it automatically prepends messages to the replaced element. That only works if the ID does not change after the initial replacement happened as otherwise the second ajax command won't be able to prepend before the old ID.

The id attribute must be unique in a document according to the html specifications:

When specified on HTML elements, the id attribute value must be unique amongst all the IDs in the element’s tree and must contain at least one character. The value must not contain any space characters.

https://www.w3.org/TR/html5/dom.html#element-attrdef-global-id

That's not the point. I'm refering to the unique ID API which adds a random suffix.

Of course it has be unique client-side, but when the ajax update happens then we replace that ID with the new content, which then can have the same ID again, there is nothing wrong with that.

If you look at other #ajax, then they almost always even use custom #prefix/suffix with hardcoded markup, exactly to prevent that Drupal messes with those ID's in any way.

Reroll & small tweaks; AJAX-callback should work now. Can't figure out how to generate an interdiff as patch file from #166 doesn't seem to apply.

Addresses/(hopefully) fixes some of the test failures.

1. +++ b/core/lib/Drupal/Core/Field/WidgetBase.php
   @@ -215,45 +217,64 @@ abstract class WidgetBase extends PluginSettingsBase implements WidgetInterface
   +              '#submit' => [[get_class($this), 'submitRemove']],
   ...
   +                'callback' => [get_class($this), 'removeAjaxContentRefresh'],
   ...
   +        '#submit' => [[get_class($this), 'addMoreSubmit']],
   ...
   +          'callback' => [get_class($this), 'addMoreAjax'],
   

   Is get_class($this) necessary? Or will $this suffice?

2. +++ b/core/lib/Drupal/Core/Field/WidgetBase.php
   @@ -320,6 +341,67 @@ abstract class WidgetBase extends PluginSettingsBase implements WidgetInterface
   +    return NestedArray::getValue($form, array_slice($button['#array_parents'], 0, -4));
   

   This seems like it might be cause of the test failures. Why -4?

1. Is get_class($this) necessary? Or will $this suffice?

I'm not sure, both seem to work, as well as static::class - don't have a preference & will implement whatever's most appropriate.

2. This seems like it might be cause of the test failures. Why -4?

As far as I can tell, we use -4 here to get "up" in the nested array from the triggered submit element to its field element to replace its previous state with it (the whole field element).

Something that does not yet seem to work correctly: removing items after having changed their order (without saving in between) - this probably needs to be addressed.

1. Is get_class($this) necessary? Or will $this suffice?

I'm not sure, both seem to work, as well as static::class - don't have a preference & will implement whatever's most appropriate.

Right, I would go with static::class, as well. As far as I know that always returns the same as get_class($this) (although PHP being PHP after all, I wouldn't be surprised to learn that there are exceptions that that... ;-)).

Regarding the suggestion to just use $this, i.e. to specify [$this, 'submitRemove'] as the callback: While that is a valid PHP callable and - in general - is actually the preferred way because it doesn't require the method in question to be static, it should not be used in the Form API / Render array context, because it is not serializable and Form/Render array may be serialized. That's why I think [static::class, 'submitRemove'] is the way to go.

Changed get_class($this) vs static::class

I have tested this patch with a content type, Address, with 3 different address fields:

Visiting address
Postal address
Delivery address

All fields can have multiple (unlimited) values.

I edit an existing Address with 1 value for each field.
I first delete the delivery address value.
I then delete the postal address value.

The postal address is deleted but is replaced with the data from the previously deleted delivery address.
The field label of field Postal address is also changed to Delivery address.

Drupal 8.5.6
Address 8.x-1.4
Patch from #179

See https://www.drupal.org/project/address/issues/2992810 for screenshots.