Closed (duplicate)
Project:
Paragraphs
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
30 Oct 2014 at 13:18 UTC
Updated:
5 Nov 2015 at 17:48 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
jeroen.b commentedCould this be an issue with file_usage database table?
Did you check the database table if the file_usage record still exists after the draft?
Comment #2
yvesvanlaer commentedHey Jeroen.b
You seem to be right, the file_usage record is doing something weird.
Situation:
- The first draft it creates a record in: field_data_field_images, field_revision_field_images, file_usage, paragraphs_item, paragraphs_item_revision.
- The second draft (where it goes wrong) it creates a record in: field_revision_field_images, paragraphs_item_revision
It also updates the values of field_data_field_images and paragraphs_item.
But more important: instead of creating a new record in file_usage, it updates the record "count" field from 1 to 2.
- The third draft (where it works as intended) it creates a record in: field_revision_field_images, paragraphs_item_revision and file_usage (acting normal)
It also updates the values of field_data_field_images and paragraphs_item.
I have added screenshots after the third time I draft something (where the module is acting correct).
You can see the count field in file_usage being updated to 2.
Comment #3
jeroen.b commentedUpdating the record count is correct, file_usage does not take revisions into account, so it should have count 2 (the previous revision and the current revision).
Is it possible this is problem with the workbench moderation module?
Did you check with other entity reference fields? (like inline entity form?)
Comment #4
yvesvanlaer commentedHey Jeroen.b
I did some dpm()-ing to figure out what was giving the warning. I tried out the paragraphs_field_update() function.
For some reason it is passing an empty value into the array_flip() function.
Maybe that is because the first draft is something special?
Or maybe it needs an "if" state around something.
What I do know is that it removes the original image value, but only after saving your first draft. You simply cannot see the original image anymore.
Hopefully there is someone who has got the magical solution :-).
Nonetheless: top class module.
Comment #5
jeroen.b commentedI think because it removes the original image because it doesn't have any field_usage records anymore?
Anyway, I'll install workbench moderation later to check :)
Comment #6
yvesvanlaer commentedThanks for looking into this issue.
Let's make this awesome module 100% complete instead of 99.99% :-).
Comment #7
ben.kyriakou commentedI've come across this same issue, and have rolled a patch. It looks like this is caused by the same problem seen in https://www.drupal.org/node/2244789 - here the duplicate calls to
node_save()cause unintentional behaviour infile_field_update()for images, and instead of bailing out prematurely the images are deleted as it's not technically saving a new revision.To fix I've added the same check in
paragraphs_field_presave()- this doesn't appear to have had any adverse effects, and now drafts work as I'd expect - the new image is correctly attached and I can move between revisions with the moderate tab and see the correct files.Comment #8
jstollerThis is identical to the patch at #2603424: Nested paragraphs get deleted when using workbench moderation and that one is already RTBC, so marking this issue a duplicate.