When creating a forward revision of a node i.e. creating multiple future revisions using Workbench or similar modules, files uploaded into file fields within field collections are not saved.
The cause seems to be a call to field_attach_update()
in EntityAPIController::save()
:
// Field API always saves as default revision, so if the revision saved
// is not default we have to restore the field values of the default
// revision now by invoking field_attach_update() once again.
if ($this->revisionKey && !$entity->{$this->defaultRevisionKey} && !empty($this->entityInfo['fieldable'])) {
field_attach_update($this->entityType, $entity->original);
}
This triggers a call to file_field_update()
which deletes any files from most recent revision that aren't present in the revision being saved:
foreach ($original->{$field['field_name']}[$langcode] as $original_item) {
$original_fids[] = $original_item['fid'];
if (isset($original_item['fid']) && !in_array($original_item['fid'], $current_fids)) {
// Decrement the file usage count by 1 and delete the file if possible.
file_field_delete_file($original_item, $field, $entity_type, $id);
This is a problem because the 'default revision' being updated is not current. It results in files from the newer revision we've just saved being deleted.
Jummonk describes a similar issue in Reverting a node (with workbench moderation) with a field collection item containing a link field results in PDOException and suggests working around this by using a custom controller class with the call to field_attach_update()
removed. This fixes the issue for me but I'm not 100% sure if this is the best way to address the problem.
Comment | File | Size | Author |
---|---|---|---|
#7 | 2058025-missing-file-in-forward-revision.patch | 3.28 KB | dgtlmoon |
#1 | field_collection-custom_entity_controller-2058025-1.patch | 3.07 KB | gigabates |
Comments
Comment #1
gigabates CreditAttribution: gigabates commentedPatch to add a custom entity controller class with call to
field_attach_update()
removed.Comment #2
cobblestone.consulting CreditAttribution: cobblestone.consulting commentedIt's been a while since this was posted and I am wondering if anyone (including the poster) has been using it since then and, more importantly, if it has been free of any undesirable side-effects.
We are facing a similar situation and are considering giving this a try.
Thanks in advance for any feedback you can provide.
Martin
Comment #3
alcroito CreditAttribution: alcroito commentedI've tried this approach, and it didn't seem to work well for my case, because removing the field_attach_update does not restore the default revision values, when saving a revision,
So rather than removing, I use an approach similar to what is described in #2353491: File Usage count for revisions out of sync/incorrect #10
So the relevant code looks like this.
But for my particular case this was not enough, and I also had to use a modified version of the sandbox module found here https://www.drupal.org/sandbox/johnpitcairn/1991516 as well as the patch in #2353491: File Usage count for revisions out of sync/incorrect / #10.
Also my field_collection module is modified to support entity translation + some other fixes, so it may vary for other people.
Comment #4
dgtlmoon CreditAttribution: dgtlmoon commentedTry this #1399846: Make unused file 'cleanup' configurable worked for me!
Comment #5
eelkeblokPatch #1 seems to resolve the issue for me. We'll need to do some more testing to be certain. I can't really comment on the proposed changes by Placinta, may look into it further if we run into more issues.
Comment #7
dgtlmoon CreditAttribution: dgtlmoon commentedre-rolled
Comment #8
dgtlmoon CreditAttribution: dgtlmoon commentedHmm did not resolve the issue for me
Comment #10
dgtlmoon CreditAttribution: dgtlmoon commentedthis issue could be a red herring for #2807793: file_field_update only considers file-ids in current revision as valid, deletes fids from future revisions
Comment #11
eelkeblokComment #12
eelkeblok