Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Hello again,
The steps I followed:
1. Created a file
2. Edited the file, "replaced" the image, clicked "new revision", submitted.
3. The file remains unchanged. The "replacement" file, however, is showing up in admin/content/file but strangely not in admin/content/file/thumbnails.
Inspecting the database,
- I see my file in file_managed_revisions, fid 15. There are two rows there, vid 15 and vid 17. The uri field for both is the same public://test.jpg. In file_managed, fid 15's vid is 17.
- In there also is the image I was trying to replace test.jpg with as its own row, fid 16, vid 16. Interestingly, the uri field for this one is temporary://test2.jpg .. In file_managed, fid 16's vid is 16.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 2099949-file_entity_revisions-handle-revisioning-of-file.patch | 1.98 KB | merlinofchaos |
Comments
Comment #1
ericduran CreditAttribution: ericduran commentedYep, this was not one of the goals of this module.
I can look into it but I'm pretty sure the actual file is being removed somewhere. That being said this does seem like a valid require so I'll look into it.
Or I can just wait ;-)
Comment #2
johnnykrisma CreditAttribution: johnnykrisma commentedI'd like to also say that this is something we're in need of as well. We have many users who want to have file revisions, not just entity information, but a brand new .doc or .pdf.
Comment #3
merlinofchaos CreditAttribution: merlinofchaos commentedThe difficulty here is that file_entity module writes the file outside of the process of file_save(). This is actually probably fairly poor behavior -- instead it should put the file in a temporary location and then move that in file_save() but that's really neither here nor there.
This patch has file_entity_revisions add a separate submit handler to the file_entity_edit form and, based upon whether the new revision checkbox is checked or not, copies the file (or uploads the new file) to a different uri that will be specific to that revision. While this means that revisions will now make copies of files, this is necessary to prevent multiple revisions from pointing to the same file, and then having one revision change the file and other revisions being affected. Because we do not have full control over the file entity, I don't think there's an easy solution to that other than just accepting you could have a lot of copies of files.
Comment #4
Fabianx CreditAttribution: Fabianx commented**RTBC** - It is unfortunate having to copy the actual files, but de-duplication logic could always be added on top using aliases and copy-on-write semantics, but its probably simplest to start by just copying the files. And regardless of implementation detail some code like this is needed.
Works great for me!
Comment #6
ericduran CreditAttribution: ericduran commentedThanks for the patch.
This is fixed now.