Problem/Motivation
I've run into a strange bug where a multi-value field collection field creates multiple revisions of the same field collection entity. I can recreate it on a pretty clean installation (using simplytest.me with the field_collection module and devel only).
To recreate...
1. Create a content type that has a field collection field called "Collection" with "Number of values" set to unlimited.
2. Create a field collection field called "Collection name" that consists of a text field only.
3. Create a new node with three or more field collection items and save it.
As expected, this creates a node with three field collection entities. The values of the field collection field are:
You can see that each has a different entity ID (the value). This is correct.
4. Now, edit the node and delete all three field collection items by clicking each "Remove" button.
5. Before saving the node, enter a value for "Collection name" in the new field collection.
6. Click "Add another item" and enter a value for "Collection name" in the new field collection field.
7. Click "Add another item" again and the value for the "Collection name" text field in the newly-added field collection will be pre-filled with the value from the one above.
8. If you then save the node, the "Collection" field collection will now contain duplicates-- the entity_id (value) will be the same, but the revision IDs are different:
This is wrong. Deltas 1 and 2 are duplicates of entity ID 10 (revision IDs 14 and 15).
Expected behavior: It should create new distinct field collection entities rather than multiple revisions of the same entity.
Also...
If you click the "Remove" button on all of the existing field collection items, click it once more for the single empty field collection, enter a value in the text field, then click "Add another item", the first newly-added field collection will be pre-filled with the value from the one above (like in step 7 above). So, you'll see the bug with the *first* "add another rather than the second.
Comment | File | Size | Author |
---|---|---|---|
#11 | field_collection-revision_id_issue-2416237-7.patch | 1.01 KB | Ashley George |
Screenshot 2015-01-28 20.53.57.png | 24.36 KB | jrb | |
Screenshot 2015-01-28 20.54.31.png | 49.81 KB | jrb | |
Screenshot 2015-01-28 20.54.21.png | 51.02 KB | jrb |
Comments
Comment #1
jrbComment #2
jrbComment #3
jrbComment #4
rbrandon CreditAttribution: rbrandon commentedGood description jrb, I saw this as well with a similar setup.
My suspicion is that the "Remove" callback that field_collections uses is leaving bad data in the form state.
Comment #5
jrbI just happened to be looking at the Field Collection AJAX module and found that, when using this module, this problem does not occur. So, this could be a workaround until this bug is fixed.
Comment #6
chokobanana CreditAttribution: chokobanana commentedI just noticed that I'm having the same problems with beta8. Yesterday beta9 was released. Has this issue been resolved?
Comment #7
jedihe CreditAttribution: jedihe as a volunteer commentedThis bug will cause an inconsistency between the field_data_ table (for the field_collection field) and the field_collection_item table: they'll only match on value = item_id, but not on revision_id = revision_id.
For anybody wanting to troubleshoot a site, I'm pasting a drush script that will construct a query for all field_collection fields having this data inconsistency. Starting from that, you can check into each separate case to decide what to do next. Please note it's hardcoded only for fields under 'node' entities.
Comment #8
darrenwh CreditAttribution: darrenwh as a volunteer and at Investis Digital commentedHi,
I'm also experiencing this issue, has anyone come any closer to a solution?
Comment #9
darrenwh CreditAttribution: darrenwh as a volunteer and at Investis Digital commentedEscalating
Comment #10
darrenwh CreditAttribution: darrenwh as a volunteer and at Investis Digital commentedI'm able to replicate in beta 10, so changed version
Comment #11
Ashley George CreditAttribution: Ashley George commentedI'm putting forward a patch to fix this.
The problem was in the 'field_collection_remove_submit' function.
The loop that adjusts the field collection item entities was using the wrong thing as an upper limit. The idea was that a dummy item is created whenever a real one was removed. This is presumably so Drupal knows to start the ids from the right point when it actually saves.
Suppose there are 5 items in a field collection. Deleting one in the UI causes remove function to delete a FC item, create a dummy one, and increment down the 'items_count' variable. Now it looks like there are 4 items in the UI, the 'item_count' is 4 but there are 5 actual FC item entities - including the dummy one.
The problem was the loop only went up to the 'item_count' value so in our example, upon deleting another item, the loop only went up to 4, when there were actually 5 items to process. This results in the array going out of whack, and the above symptoms occurring.
Comment #12
darrenwh CreditAttribution: darrenwh as a volunteer and at Investis Digital commentedSetting to needs review
Comment #13
ray17n CreditAttribution: ray17n commented#11 worked for me. Thank you.
Comment #14
rbrandon CreditAttribution: rbrandon commented#11 fixes the issue for me as well. Thanks.
Comment #15
darrenwh CreditAttribution: darrenwh as a volunteer and at Investis Digital commentedSetting this as Reviewd
Comment #16
jmuzz CreditAttribution: jmuzz commentedUnfortunately the proposed solution does not work when the "Hide blank items" setting is unchecked. I am not sure it is progress either because the form does seem to work without the patch if that setting is unchecked.
The blank items being created are an earlier attempt to fix similar behaviours.
The form does seem to work in 8.x-1.x. You can find very similar code in src/Plugin/Field/FieldWidget/FieldCollectionEmbedWidget.php . I've been looking at it and trying some similar changes on 7.x-1.x based on what's there but so far I haven't gotten it working any better either.
I do notice that the 8.x-1.x version is hiding the blank items by making a change to items_count while the 7.x-1.x version is returning from the field_collection_field_widget_form early and making a change to #max_delta. I think that might be the source of the differing behaviours.
Comment #18
jmuzz CreditAttribution: jmuzz commentedMy bad, I had made a mistake when testing.
This is committed and will be in the next dev version.
It probably won't be able to work the same as the 8.x-1.x version unless we implement a custom behaviour for multiple value field collection fields.
Comment #19
Ashley George CreditAttribution: Ashley George at Investis Digital commentedGreat news, thanks!