#51 set me on the right track. I had a view with a relationship to another entity with multiple cardinality. Each additional reference was causing a another row for the exact same entity. By setting a filter on the delta and only showing those with delta = 0, it limited the results to one per actual entity, despite having multiple references to another entity.
I tried to implement hook_views_query_alter() but I kept getting weird results with ViewsBulkOperations so I opted for the filter against the delta instead.
I've attached a patch below, I would not consider my changes to be good code but it makes a proof of concept and seems to work (solves the case above). I've attached a 'TODO: refactor' where we would want to come up with a more intuitive way of assigning a unique ID to the #name attribute.
Drupal Form API requires a '#name' attr on the form element to find the correct triggeringElement. Originally, there would be naming collisions when you have both:
- elements that have the same parent
- elements that are using the same field
When the form is being built, it attaches a delta to the name in an attempt to resolve this. This does not work in all cases--in this case, we are using 2 instances of the same paragraph type. It duplicates the names because deltas will be unique within the paragraph instance but not on the form itself, so two instances of identical paragraph types will result in fields with the same #name such as 'field_link_1_remove_button'.
Now, there should be no duplicated names on the form. Look for the '@TODO' tag (line 225). I'm not sure if this is the best way to name the Remove buttons or not.
To create the unique name, I simply implode the array_parents--no matter what element/field/grouping, this series of items in array_parents should be unique for any form element because it also keeps track of deltas across the entire render array--and then we also attach the local delta (it's position amongst its sibling elements) since that won't be present on array_parents.
Some reading I did:
https://drupal.stackexchange.com/questions/154387/why-does-triggering-el...
https://www.drupal.org/project/drupal/issues/2546700 ✨ Add support for detecting the triggering element when buttons are changed client-side Needs work
Awesome, thanks for setting that up @progzy, I did confirm it was still messing up with your test environment. Looks like when I try to delete l1.2, it replaces that reference with the second paragraph. But then if I try to delete something from l2.*, it brings back l1.*. I'll look into my patch and see if I can't figure out the problem.
@progzy Thanks for the feedback.
I tried to recreate the same situation as yours. I added the text fields (limit 1) and links (unlimited) to the paragraph and then added the paragraph to a content type with unlimited cardinality. But when I hit 'Remove' on the 2nd paragraph instance, 2nd link, it successfully deleted it.
I'm going to try and recreate your bug on a fresh install but I thought I'd get back to you asap first. If you could, and if you think it's relevant, could you paste the 'Response' from the AJAX call that you see in the debugger?
Running D8.6.5, will try on 8.6.7 but I don't think there should be much of a difference. (Edit: oh I thought I saw you were on 8.6.7 but you're also on 8.6.5. Perhaps one of my custom modules is interfering so regardless, I'll try this patch on a fresh install and see what happens).
Sorry, some debugging statements got left behind. Here is a cleaner patch:
Hi Peter. I think I'm experiencing similar issues to yours. Is your address field inserted within some sort of wrapper for the form display? I.e. a paragraph reference, a container/fieldset/details/form group, etc, or anything like that? A site I tested this on is using the Link field within a nested paragraph and all the fields we wanted the 'Remove' button on was nested using a form group. I'm not sure what kinds of nesting might affect this but the Form Display for this specific paragraph type wraps all of our components within a 'field_content'. Thus the form displays within a container class on the front-end.
I think this wrapper was breaking the patch at Line 371. As such, I've made a slight correction to it which got it to work on my machine. It was looking for a value $user_input[$field_name] but it seems that it's not finding the value because it's not prefixing the form array with the correct keys. YMMV as I'm not entirely too sure what the actual underlying issue is.
Patch attached below.