When "Retroactive update" on filefields in nodes with revisions, only the last revision gets updated.
This happens because even if in filefield_filefield_paths_batch_update() retrieves the correct list with nodes, in filefield_paths_batch_update() the list is flatten using array_unique().
Steps to reproduce:
1) Create a file field on a node type, set to public://
2) Attach two fields to the node and save
3) Create a new revision and delete one of the flies, so that the first revision has both, the second only has one.
4) Change the field to private://, check the retroactive update box, and save the field settings
5) Observe in the file_managed table of the database that the file entity that is still attached to the current revision has been converted to private://, however the file entity only attached attached to the first revision, deleted from the second revision, is still public://.
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | filefield_paths-retroactive_update_doesnt_update_old_revisions_of_nodes-1115740-10.patch | 20.88 KB | jaypan |
Issue fork filefield_paths-1115740
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
simon georges commentedClosed #1127456: Retroactive updates doesn't move old revision's files as a duplicate of this one.
Comment #2
decipheredNo longer supporting Drupal 6 issues for this module.
Comment #3
j_s commentedThis issue is still relevant in the Drupal 7 version. In my case, using the retroactive update, files in revisions are not moved. Only the latest version is moved.
Comment #4
jaypanThis issue is still present in version 8.x.
Comment #5
jaypanComment #6
jaypanRemoving D7 example, as architecture has changed.
Comment #7
jaypanComment #9
jaypanComment #10
jaypanHere's a patch for 8.x-1.x for a stopgap, as the merge request is for the -dev branch.
Comment #11
jaypanMoving to needs review.
Comment #12
liam morland