File revisioning should try to preserve the filename

**RTBC** - And its raining cats and dogs! - But the right one for each revision!

Works great! Thnx..

I personally would rather see it saved as cat.png. What if there is a link on the website to the file, suddenly the link is broken? Not saying not to fix it, but not taking it in a different direction from how drupal core normally handles file replacements.

#4: But the name is and cannot be preserved (its called cat_1, cat_2, cat_3 already).

What you want is permanent image uri's, but that is a different story.

With revisions you do not want the dog to be suddenly on the live page, because it overwrote the cat ...

This is for modules like workbench or CPS.

I just wrote a patch that preserves the original name forever, and stashes revisions as _2, _3, etc. I will share once I figure out how to format patches on here. It works very well and you can also revert and still not lose the filename. The idea is in large websites people may want to replace a form, but they don't want to update the links to those form. If the filename changes, the link breaks. If you want to replace cat with dog, delete cat and upload dog as a separate file. That's my intent anyways, and that's how Drupal does it with file edit/replace.

@pcrats33 Sounds great. Regarding patches you might want to check this page: https://www.drupal.org/node/707484

Ok here is the patch.. This makes it so the original filename for a file stays that way as long as you are replacing the file. Also I was originally working on a patched version from https://www.drupal.org/files/issues/files_ought_to_have_a-2097975-14.patch which I highly recommend be included in a new version of this module. If you applied this patch as I did, you will also need to add a couple lines to the file_entity_revisions.pages.inc file:
function file_entity_revision_revert_confirm_submit() : around line 128.

  $file_revision->log = t('Copy of the revision from %date.', array('%date' => format_date($file_revision->timestamp)));

+  // Swap out current revision with new one for names sake
+  $file_original = file_load($file_revision->fid);
+  $last_file = $file_revision->uri;
+  $file_revision->uri = _file_entity_revisions_replace_file($file_revision, $file_original);
+  if ($last_file !== $file_revision->uri) {
+    // Delete previous stashed file as it has been renamed.
+    file_unmanaged_delete($last_file);
+  }
  
  file_save($file_revision);

  watchdog('content', '@type: reverted %filename revision %revision.', array(

...and it works as designed. Perfect. Thanks!

I'm updating the patch, I found an error in functionality - when editing a file but not changing the file, it tries to replace the file with itself, but file_unmanaged_copy returns a FALSE in this instance, and the file->uri is replaced with the false value. This new patch handles that case so that the file URI isn't lost.

Here is another use case.

We are having a similar issue where cat January 2015.pdf is the old version and cat February 2015.pdf is the new version.

• If we don't use the new name for the new file, the filename will be misleading.
• If cat January 2015.pdf is retained in the public file system, people coming from Google, which has indexed cat January 2015.pdf, will get the out-of-date file.
• If cat January 2015.pdf is moved to a revision file system, people coming from Google, which has indexed cat January 2015.pdf, will get a not found, which is unfriendly.

What we would want to happen is the new file retains the new name cat February 2015.pdf and the old name redirects to the new name.

So, maybe this is a configuration option in the module?

Sorry, I see this is covered in comment #5. Sort of.

The problem is, if the original file name has the date in the name, then we don't want to keep the original file name, as it will give a wrong impression. We would only be okay keeping the old file name if it had no misleading content.

It is fairly common in our organization to use dated file names, so we would not want to keep the same file name, we would want the redirect to the new name instead.

@Charles Belov, you are correct in your last comment of "we don't want to keep the original file name" if it contains some kind of date. It would be better to have the first file, or you could change the file name, to something more generic with no date in it. Then when you upload a new file, in your example with a date in it, that file will replace the original file. However, the URL will stay the same and the way we have it set up now, both versions are retained on the server so you can always revert back to an older file too.

Realistically, nobody on our staff is going to go in and genericize the file name. And we don't want to retain the out-of-date file, unless the file name is changed in some way, because Google has likely indexed the old file and we don't want to serve the old file. What we really want is to serve the new file regardless of whether the old or new file name is used.

However, Workbench Moderation revisions prevent the old file from being deleted in IMCE. So a rename of the old file would be better.

I guess the bottom line is that this would best be a configuration option, not a do always.