Breaking this out from another issue. Original comment by @haleagar at #2271229-18: Allow file replacement extensions for the same file type:
Just a note: this causes a drastic change in behaviour compared in file_entity 7.x-2.0-beta1 and file_entity 7.x-2.0-beta2 vs file_entity 7.x-2.0-alpha.
In file_entity 7.x-2.0-alpha and previous versions if you use the file replace option the original file name (in the file system) was retained and all hard links to that file remain valid.
After this change the file name (in the file system) is changed and any links to the file such as use in a wysiwyg field are broken.I realize that either behaviour could be argued as correct, but in my opinion the previous behaviour is a more desirable and expected behaviour than the new.
I would say it is *much less* often needed to upload a new image file that has a different extension, than it is to replace a file with one of the same type.I would suggest that it would be desirable to modify this function such that the file name is only changed when needed by a change in the file extension, or possibly only when expressly requested by the user by a option on the edit form.
We've trained our users to use the file replace tool to update files without breaking URLs all over the place, so for us this is a major regression.
Attached is @haleagar's patch from the other issue.
| Comment | File | Size | Author |
|---|---|---|---|
| file_entity-replace-file-retian-name-if-of-same-type.patch | 2.01 KB | chaseontheweb |
Comments
Comment #2
joseph.olstadComment #5
joseph.olstaderring on the side of caution here;
this workflow comes at a cost of perhaps loosing revision data in that the physical file is actually replaced.
I think the idea behind this is to keep revision information in the filesystem.
when using file entities in views , there is no content editor /update problem here, automatic
when using file entities in media, there should be no problem here (given a correct configuration on a stable release), automatic again. maybe a cache clear.
I'm open to discussion though.
Comment #6
joseph.olstadComment #8
joseph.olstadok, after reviewing the parent issue for this
#2271229: Allow file replacement extensions for the same file type
going with @haleagar's reasoning. I agree.
Comment #10
jenlamptonI'm still seeing this problem in 7.x-2.2 in spite of a fix being committed in this issue. Here's a link to a new issue: https://www.drupal.org/node/2887487