I am running a Cloud based site and trying to hook MediaService.Saving via a composer event. The code works perfectly when I run it as a local project but doesn't seem to work at all when I move it up to the Umbraco hosted environment.
I'm happy to share the code, but I'm wondering if it's not the code as much as if I'm trying to do something that isn't supported?
Ok, I've narrowed down a few things, but still puzzled. My code is saving Media to S3, which is working great. However, the client's requirement is to overwrite existing media when using the "Remove File" functionality instead of creating a new file for the purpose of retaining URLs in the media folder. This is also working now with some custom code.
When I run the project locally, everything works perfectly! When I move the same code to Umbraco cloud, it no longer works and I have figured out why.
When you use the Remove file(s) button in the backoffice, then "Click to upload" a new file, then click save, this calls MediaService.AddFile(string path, Stream stream) - when that code is run locally, "path" returns the current media item's path, same code on the server returns the new file item's path making it impossible for me to search S3 for the Key, because it won't exist.
Not sure what to do from here. I can search every key on S3 and try to find it, but then what?? Update every file that has the same name, that sounds heavy handed.
Super stuck and could use some help. Again, I have no problem with saving to S3, and no problem doing Updates (as opposed to create) - my issue/question is why does AddFile get sent the path to the MediaItem being updated when run locally, and get sent the path to the MediaItem being Uploaded on the server?
I suspect this is tied in to some core code somewhere because local projects media directory structure is like 'ffyn4h4y' where hosted media file structure is like '8d85ce529857aee' - Local projects (with or without my custom save code) allows for updating files without changing paths, hosted files do not.
Composers on Cloud
Hey All,
I am running a Cloud based site and trying to hook MediaService.Saving via a composer event. The code works perfectly when I run it as a local project but doesn't seem to work at all when I move it up to the Umbraco hosted environment. I'm happy to share the code, but I'm wondering if it's not the code as much as if I'm trying to do something that isn't supported?
Thanks,
-Roger
Ok, I've narrowed down a few things, but still puzzled. My code is saving Media to S3, which is working great. However, the client's requirement is to overwrite existing media when using the "Remove File" functionality instead of creating a new file for the purpose of retaining URLs in the media folder. This is also working now with some custom code.
When I run the project locally, everything works perfectly! When I move the same code to Umbraco cloud, it no longer works and I have figured out why.
When you use the Remove file(s) button in the backoffice, then "Click to upload" a new file, then click save, this calls
MediaService.AddFile(string path, Stream stream)- when that code is run locally, "path" returns the current media item's path, same code on the server returns the new file item's path making it impossible for me to search S3 for the Key, because it won't exist.Not sure what to do from here. I can search every key on S3 and try to find it, but then what?? Update every file that has the same name, that sounds heavy handed.
Super stuck and could use some help. Again, I have no problem with saving to S3, and no problem doing Updates (as opposed to create) - my issue/question is why does AddFile get sent the path to the MediaItem being updated when run locally, and get sent the path to the MediaItem being Uploaded on the server?
I suspect this is tied in to some core code somewhere because local projects media directory structure is like 'ffyn4h4y' where hosted media file structure is like '8d85ce529857aee' - Local projects (with or without my custom save code) allows for updating files without changing paths, hosted files do not.
Thanks - Sorry for the long post
-Roger
is working on a reply...