It always takes me way more time than it should to use this uploader properly.
The problem is that I 99% of the time have to manually configure a “Delete unused images from storage” workflow to avoid storing what doesn’t need to be stored. It always is a pain.
It’d be really appreciated to have a single “Delete unused images” checkbox added to this tool, so we don’t have to manually fiddle with it all the time.
Just to be clear: unused images are the ones that are not used by auto binding and/or hasn’t been submitted to a workflow; like when a user decides to replace the held image in the uploader before hitting “apply”.
Yes, this is a pain. All file uploaders (whether images or anything else) have this same “problem.” While it’s not a problem inherent to Bubble alone, it would be very helpful if a native system were implemented to handle it.
There should be a way to identify images/files that aren’t linked to anything through the File Manager, again, in some native way.
In fact, it’s possible to perform some action to verify this through the file URLs, but for apps with thousands of entries in the File Manager, trying to retrieve the URLs and list them to process, before comparing, is a nightmare.
Haven’t really used file uploaders that much just yet so I didn’t knew about it but this just makes the problem worse.
I also thought that there could be a frontend way to temp-store images (or files for that matter) before definite submission, so we aren’t forcing our storage workflows without distinct reasons.
you might know this .. whatever user uploads needs to be deleted, it’s in 2 steps. 1. from the web-hosting service(AWS) Delete uploaded file and then also delete the url saved in the data base for that image just by keeping the logo field empty.
I’ve used this before but It’s a double edge sword in some cases.
You only want to delete storage of items if/when those are not used or linked with a database entry. If you delete something with the same workflow upon upload it will result in file losses on the long term. I’ve lost a bunch of profile images before I figured this out.
The way I do it today is I store the uploader’s value in a custom state via link text and if the user hits cancel or if the uploader’s value changes before submission, it’ll finds and deletes the file held in the custom state and replaces the link with the new one in case if that one is also going to be unapplied or cancelled.
It’s still not the most secure way however because if the user looses connection with the app, the file held in the uploader will stay there forever and never get a chance to be linked with a database entry or deleted, right until a sweeper workflow doesn’t come and clears out everything that is unlinked, which, as @Newed pointed out before, is a tedious workflow.
There are a few approaches about this. You’ll find some threads about this discussion; this is an old issue.
The custom state approach works, but it has this problem you reported, of losing reference if something happens on the front-end that interrupts the connection.
One approach you can use is to have a datatype (orphan_file) to add the references (URL) of any file/image the user uploads, whenever they upload it, regardless of whether they decide to save it or not.
Then, when the user actually saves the file/image, you remove the reference to it from this datatype.
And then have a recurring action to clear everything in the File Manager that has a reference saved in this datatype. Also remove from the datatype the same references used in this process.
This avoids:
Problems when trying to manage unsaved files through custom states.
It centralizes and makes all control modular in one place, avoiding the need to create flows to control states in every file/image uploader.
Keep in mind that this is not an approach for those who care about every tenth of WU consumed.
