Closed (fixed)
Project:
File Entity (fieldable files)
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Reporter:
Created:
11 Apr 2011 at 14:49 UTC
Updated:
25 Mar 2013 at 22:24 UTC
Jump to comment: Most recent file
Comments
Comment #1
grossmann commentedI second that. It would be nice to have the possibility to update files without loosing the added metadata or have to relink a file which is linked to from many sources.
Comment #2
krisahil commentedAgreed that this would be awesome feature. Any media.module developers want to point me in right direction to start developing this as feature?
Comment #3
dave reidYou could probably form_alter the media_edit form to add an upload field, validate that the uploaded file matches the same file type as the existing file, and then in your custom submit handler re-save the file record (actually probably just updating $form_state['file'] should do it since media_edit_submit() runs file_save() already.
Or add a new local task at media/%file/replace to do this for you.
Comment #4
dave reidYou could probably form_alter the media_edit form to add an upload field, validate that the uploaded file matches the same file type as the existing file, and then in your custom submit handler re-save the file record (actually probably just updating $form_state['file'] should do it since media_edit_submit() runs file_save() already.
Or add a new local task at media/%file/replace to do this for you.
Comment #5
krisahil commentedThanks, Dave. I'll give this a go in the next few days and post the code, if it works.
Comment #6
krisahil commentedI finally got a chance to build a module that implements replacing the file of a media/file entity. However, it only works up to 7.x-1.0-beta4 release. It's rough but works in my limited testing:
http://drupal.org/sandbox/krisahil/1268978
In better news, looks like someone tackled the same problem but did a much better job of staying in the media.module and new Drupal File API system (and it says it works with media.module releases 7.x-1.0-beta5 and 7.x-2.0-unstable1):
http://drupal.org/project/media_update (via http://achieveinternet.com/blogs/drupal-development/achieve-releases-med...)
Hope this helps people with the same problem.
Comment #7
effulgentsia commentedThis is a "won't fix" for Media 1.x, but I think is a valuable feature for 2.x. Moving this to the File Entity project (which provides the base file management capabilities used by Media 2.x) for evaluation there. Great to know the Media Update project has some working code for this: it might make sense to move some of that to File Entity.
Comment #8
dave reidComment #9
effulgentsia commentedThe maintainer of Media Update is wanting File entity / Media 2.x to stabilize more before putting effort into updating that module to be compatible (#1460560: Does this module work with Media 2.x?). But who knows, maybe he'll be open to reviewing a patch if someone wants to submit one. Cross-linking these two issues for reference.
Comment #10
dave reidI'd be open to reviewing an issue for it.
Comment #11
moniuch commentedI hope the relink feature will be able to fix broken media references as well
Comment #12
dave reid@moniuch: Could you elaborate what you mean by "broken media references"?
Comment #13
moniuch commentedi mean situation where a file suddenly becomes unavailable (accidental deletion from server) and the new version of file needs to be provided as substitution.
Comment #14
dave reidYeah this feature should work for that use case.
Comment #15
gmclelland commentedFYI... There is a project that needs review http://drupal.org/node/1301558 (File Replace)
This might do what you are wanting, haven't tested it.
Comment #16
dave reidI'm aware of the file replace project, but it is way over-complicated for the simple functionality that I'd like included natively in File entity.
Comment #17
edward.kay commentedThis looks like great functionality to include. What are the next steps for implementing in File Entity?
Comment #18
brentratliff commentedI have some of the code for swapping media at http://drupal.org/sandbox/brentratliff/1592862. It doesn't handle importing all fields but it does replace an updated image in other entity's filefields where the original was used. Currently it does transfer the fields supplied by Photo Flow and it probably wouldn't take much to have it transfer all fields. It's only tested with Media 2.x.
Comment #19
dave reidFor anyone looking to work on this issue we have some working and tested code that we developed for this issue for a client, but we're still awaiting payment from the client before we can post and commit the code.
Comment #20
brentratliff commented@Dave Reid,
I will hold off then. I think there is a lot of duplication of efforts here on which we can collaborate. I think it's best this functionality live in File Entity itself and am willing to help when needed. Feel free to ping me here or in IRC for testing/coding/etc.
Comment #21
dave reidWe just got the clearance and payment from the client so now we can get a public patch ready to go! I hope to have this committed by tomorrow!
Comment #22
dave reidInitial patch to run by the test bot since I've made a bunch of cleanups from the 1123570-file-replace branch that's now published on drupal.org.
Comment #24
dave reidAdded some debugging.
Comment #26
dave reidOk think I've figured it out.
Comment #28
dave reidComment #29
dave reidOk here is the formal patch based off a diff between the branches 1123570-file-replace and 7.x-2.x.
Comment #30
dave reidI have merged the branch with 7.x-2.x! Thank you to drupalmonkey and becw for working on this code, as well as a thank you to Aquantum for sponsoring paid development time to get this feature in!
http://drupalcode.org/project/file_entity.git/commit/4f07d095
http://drupalcode.org/project/file_entity.git/commit/2250c8e6
http://drupalcode.org/project/file_entity.git/commit/a39488e8
Comment #31
fangel commentedHi.
This is a slight issue with a user-experience inconsistency, that was brought up over at #1426730: Automatically open the file edit modal after uploading a file. Namely that if you just add a file via file/add, you get redirected to the file/:fid/edit page, where you're then able to immediately replace it with another.
But if you do, you aren't once again presented with the form to edit the title of this new file (like you do when you normally add a file), instead you're sent to whatever ?destination you have (or admin/content/files if no ?destination, iirc)
IMHO the replace-file field doesn't make sense on just-created files. Would it be possible to remove the option to replace the file if it's just been created?
Regards
Morten
Comment #32
dave reidYou would edit the title when replacing the file the first time. Any changes on the form when you also upload a replacement will also take affect. I don't really see the big usability issue here, plus adding more logic on the file/%file/edit page makes me uncomfortable with end-user expectations that they should be getting a consistent form.
Comment #33
moniuch commentedAs a user, for a freshly uploaded file, I would gladly see a static text with the file location (ie. where the uploaded file has been saved into) in place of the file-upload widget. I believe this kind of show/hide behavior is not overcomplicating of the UI.
I also believe, some day we're going to have the file re-location feature available. At that point, the path confirmation label could be expanded to have a "Move this file..." dialog.
Comment #35
grossmann commentedThe edit file function works well for me but one thing i expected to work different. If I replace a file on the edit screen i get an name field and a file select field for the new file. If the new file has the same name everything is ok but if the new file has a different file name i can edit the display name in the upper name fild but the original file name stays the same. This is very confusing especially if the files should be downloaded (which i asume files would be generaly) because the downloaded file has NOT the new name but still the old and outdated one.
My assumption was that whatever i put in the upper name field will be the new file name (not just the displayed name). Even better would be an option/check box the "use filename of uploaded file" which uses the same name the new file has.
I see the problem with the possibility of conflicting filenames with already existing files. But this should be able to be handled by the standard drupal filename serialization or am I wrong.
Great work so far. This makes life so much easier for file management in drupal.
grossmann-mcs
Comment #36
brunogoossens commentedI made a module (a wile ago) that has the same functionality than the patch above. Maybe some extra code can be reused in the file entity module.
http://drupal.org/node/1301558
The module has the ability to replace files and keep the same file id for it. I made it to use in combination with the filefield_sources module. Files can be attached to multiple nodes so I needed a functionality to replace the files without losing the relations.
I also added functionality for replacing image files. The width and hight data needed to be updated.
Comment #37
scuttlest commentedHey - we've been trying to use File Entity to handle replacement of files on our site, but we haven't been able to do what we expected and aren't sure if we're using the modules correctly.
We are developing an architecture that our users will update and maintain after we're finished. They want to be able to replace outdated files (such as a staff directory) with an updated version so that all instances of links to that file are replaced with the new file; our hope was that, if they attempt to upload a file, via embedding it into a textfield, whose name is already taken [trying to upload directory.pdf if there's already a directory.pdf in the location folder], there would be a way to tell Drupal to replace the old file with the new one being uploaded.
We've been using media 7.x-2.x-dev and file entity 7.x-2.x-dev to try this out but we haven't been able to make it work - we're not sure if we're doing something wrong or misunderstanding the way this feature is meant to be used. Any suggestions?
If I need to clarify something let me know, I'll be happy to.