Add a delete button on the field-collection item edit form

Subscribe.

When I click the new Delete button, it show the Page not Found page

and the URL goes to this invalid address:

http://localhost//delete?destination=node/4

subscribe. I'd like to see this on the widget too.

Yes, I find it counter-intuitive that it is (by default) on the View page for the node but not on the Edit page's widget. It is true that you can set all the collection fields to their "empty" value to remove the collection entity, but this can be tedious if you have more than two fields in the collection.

@JustMagicMaria, that is primarily because deleting a field isn't provided by core yet: #1038316: Allow for deletion of a single value of a multiple value field.

I'm going to assign this to myself, hopefully I can work on this during the week.

subscribe

Right, thanks for that.

Sorry for that tim, I definitely didn't change it, or intend to change it. I'll have to take a look at my chrome extensions and see if they are interacting with webforms in an undesired behavior.

Sub

subscribe

+1 subscribe

subscribe

subscribe

subscribe

sub

Hi and thank you for your work.
This featured was a real need for me, but it didn't fit exactly. The path was not good and I got some underscore instead of "-" in the field_name.
So I tried to fix the problem and I changed your "$form_state['redirect']" initialization by :

   $form_state['redirect'] = 'field_collection/' . $field_collection_item->field_name .'/'.  $field_collection_item->item_id .  '/delete';
   $form_state['redirect'] = str_replace('_','-',  $form_state['redirect']);
   $form_state['redirect'] =  array($form_state['redirect'] ,  array('query' => $destination));

So this is working for me.
I don't know if it's good or not , but if it can help...

Subscribing

sub

subscribing

I'm using 1.x-dev and can't delete a row even if it's blank, which I'm reading is the current way to remove an item. This means that editing/saving a node with an unlimited field_collection 10 times results in 10 new blank rows that can't be removed. Until this is resolved, is there any way to delete these blank rows?

@csdco:

For that issue, you're going to want to look at this thread: #1239946: Embedded field collection items with a default value result in new items on save.

subscribe

+1 for there being a remove button on the node edit form

there are a lot of bugs in this module at the moment; and although a remove button isn't the right way to fix them; it does make for a nice stop gap until some of the other issues with collections get sorted out.

subscribe

@adam_b: Stop subscribing, start following:
http://drupal.org/node/1306444

wow! it's finally happened!!

still have the delete problem, though...

Here it is my current jQuery code

    /* Weird but needed, removes the new button if the jquery runs again in the current page */
    $('a.del-field-multiple').remove();
    /* Add a delete icon for fields with multiple-values */
    $('div.form-item tr.draggable').append('<a class=del-field-multiple href=# title=Remove></a>');
    $('.del-field-multiple').click(function(e) {
      $tr = $(this).closest('tr');
      $tr.find('input').val('');
      $tr.find('select').val('_none'); // in my case, I have a select that need to be cleared
      $tr.fadeOut('', function() { $(this).addClass('hide'); }); // add a class to hide it
      return false;
    });

todo: if the user clicks the Add new value, the removed ones return! it is probably in drupal cache_form, an ajax call is required to clear it when we delete it. Or a simpler, temporary and faster way, to use a js array to add back the .hide class

far from the ideal solution, but I need this working ASAP here.

I will post again when I get any progress.

This one is more or less in keeping with how the Add More button works right in Field UI. It's a little bit complex for a number of annoying reasons but I think this patch covers the bases. It's more complex than the previous patches because it really has to take into account moving data around in $form_state['values'] properly or the widgets get their values crossed up.

@merlinofchaos: Thanks a lot! Looks good so far.

There seems to be one problem. Removing the very last item in a field collection does not work. It just won't disappear.

Also, if that last item is the default blank item, and I delete it, the second-last deleted item will re-appear and is not deletable.

Another thing:

Since I have default values in my field collection, I don't want that default item anyway (at least I don't want it to get saved). So before I was using the patch in #13 from here: #1239946: Embedded field collection items with a default value result in new items on save.

But that patch doesn't work well together with your patch. If the first of multiple items is deleted, it will be replaced (and duplicated) by the item right below it. Deleting it again will finally remove it.

You can't delete the very very last item. Field UI always gives you one more item than you have, so the final item should always be a blank one.

That might suggest that the code that is renumbering the entities back down might be failing slightly though, so the blank entity is getting filled in from an entity it shouldn't be. I'll see if I can figure this out.

Ok, right, in the current mode there is always a blank item attached. But it's got a delete button!

So, conceptually this would makes sense: When the very last item is deleted, it will be replaced with the blank default item.

Also considered should be a (very last) blank item that got filled out already. This should be reset to an empty blank item.

For me this still wouldn't work at the current state of this module, because my collections have default values... That's another topic, but possibly related.

Yeah, collections with default values are problematic because they will never show up as 'empty'.

I don't have an answer for that, except to try to avoid required and default values in collections.

Well, generally removing the blank item was working quite well for me so far. (#13 at #1239946: Embedded field collection items with a default value result in new items on save)

Only the Delete button was missing...

Ok, added code to make sure that if there are no entities, there is a blank entity so it does not try to reload the entities from the database, which is how entities were getting resurrected. Try this patch:

Great, that works better.

But items still get resurrected. When I open a node with several field collection items and I delete them, they all come back if I press the "Add" button. There very first might get wiped if I delete hard enough, but all others will reappear...

Do they call come back at once when you click add another? I do see them sort of coming back when I add another (which is weird!) but I only get 1 per add another button.

Ok, new patch!

This also addresses the (*&)(ing changing html id problem and it retains blank entities so that field collection doesn't try to reload them from database when they're deleted.

This one requires a menu rebuild.

#36: Sorry for not being precise. It was exactly how you describe. Didn't mean they all come back with one click, but one after the other with several clicks.

#37: Excellent, very good work! This is almost perfect. I played around with it and it looks very robust. I tried hard to make it fail, but I couldn't. It's just doing what's expected.

Ok, I said almost perfect. There is only one little thing left that's not considered. It's minor, but it's there:

When I reorder the items via drag and drop and afterwards remove any item, then all the reordering is replaced by the original order.

Adding a new item does preserve the order.

If this was fixed, then it would be truly perfect.

Oh, I hadn't even thought about re-order. I hope that's not too big of a pita.

Well no. Tiny pita. Thank you so much for the work that you did! This is more then acceptable and a huge improvement for this module.

I don't know if this qualifies for being fixed like this, or if it should stay open maybe 'minor'. Maybe it's a new issue.

Anyhow, I'm happy with it (besides that I now have to find a new solution for the "blank item with default values" issue).

Man that was a pain. An error in the calculation on the form state input was causing it to just blow away the input rather than store it. What's weird is...I don't know why regular input was working but weight was dying. That was some voodoo there; it shouldn't have worked *at all* in that state.

Anyway. Try this one!

Mhhm... with that voodoo it was working better.. :-/

Now I have two issues:

1. If I remove the very last item, I get an ajax error (alert popup in the browser):
"Recoverable fatal error: Argument 2 passed to drupal_array_set_nested_value() must be an array, null given, called in /mysitepath/public_html/includes/form.inc on line 2436 and defined in drupal_array_set_nested_value() (Zeile 6330 von /mysitepath/public_html/includes/common.inc)."

2. When deleting one of multiple items, the blank item from the bottom moves up to some (random?) position between the remaining items.

Nifty! I thought I tried all those combos. Back to work. :/

One. More. Time

So the second issue in #43, where the last item would go to a random place, was because the 'weight' field used by tablesort is a select numbered from -x to x where x is the number of items. If you have 4 items, and the last item is weight 4, after removal the max weight will be 3; the browser doesn't know what to do with 4 so it actually sets it to whatever it feels like.

Hopefully this is the last one I need to do!

While I was at it I improved the documentation and did some more thorough number crunching to make sure that my calculations are correct.

+++ b/field_collection.moduleundefined
@@ -896,12 +909,175 @@ function field_collection_field_widget_form(&$form, &$form_state, $field, $insta
+/**
+ * Sort callback to resort $form_state['input'] by weight.
+ *
+ * We can't use the one in core because it works on $form not
+ * $form_state and looks at #value. Other weight sorts look at
+ * weight, not _weight. So we need our own.
+ */
+function _field_collection_sort_items_value_helper($a, $b) {
+  $a_weight = (is_array($a) && isset($a['_weight']) ? $a['_weight'] : 0);
+  $b_weight = (is_array($b) && isset($b['_weight']) ? $b['_weight'] : 0);
+  return $a_weight - $b_weight;

It doesn't look as nice, but what about _field_sort_items_helper()?

Ok so I missed that one when I was looking for the sort helpers.

This can go either way; the function starts with an _ so technically we're not allowed to use it out here in contrib.

Ok, using core's sort helper and fixing a typo in doc. Otherwise the same as last upload.

Thanks merlinofchaos for the great patch and documentation, and thank you jox for testing it.
I've tested it as well, and it works great.

http://drupalcode.org/project/field_collection.git/commit/a0dc28f

Great! Now it's truly perfect. Even the sorting issue is solved. Kudos to merlinofchaos. And thanks to tim.plunket for committing.

Just downloaded de dev version of NOV 15, 2011 and ... patch is already committed and it works great.

Thanks Merlin & Jox

Same here

Great work, mighty Merlin!!! Thanks² a billion

Amazing - Working perfectly here too!
Tnx

oops!
I use the dev version of module and fortunately I see the delete button in the collection field rows. but it does not work even when I have more than one row,.
what is the problem? when I press delete button it shows me such error:
An AJAX HTTP request terminated abnormally.
Debugging information follows.
path: /radaahang/field_collection/ajax

@pegah_m : please post this as a new issue/support request, this one is fixed. You can always links to this issue for reference. Thanks.

ok
thanks for your reply

Anyway my problem is solved by removing the parent group of my collection field

Delete button only works for one item, doesn't do anything to second or third item, tried this with 7x-1.x-dev.

@cesar.perales:
This issue is long closed.
If you have found a bug please open a new issue.