Hello, I’m pretty sure this is a bug but if its not please give me an explanation for this Bubble behavior.
What I’m trying to achieve is to display the original text(placeholder) of the PictureUploader after deleting the uploaded value via event in the workflow. It keeps displaying the previously uploaded image even if the value is deleted and I can’t display the original text(placeholder).
PictureUploader NEEDS TO BE UPDATED!
PictureUploader is essential for an app that handles images but the behavior such as switching a text to an image in the uploader itself is quite troublesome for developers and limiting the freedom of this function. I really think making this “switching to image behavior” an option is a must.
I think I know what you mean. It would be nice to not have to do extra steps and wish it would just work like we want it to.
This is usually the process that I do to make it work the way I want it:
When uploading the image, save it somewhere right away and then make sure to reset inputs. You can save it to a set state or the database whichever one makes more sense. Then display it back as the background image of the uploader. Then when you delete it, it will clear out the uploader. You can also have a background image as a default image you choose as well. The background image seems to work more like we want it to. It’s more like the ‘image behavior’ that we are used to.
Strictly speaking, it’s not “essential”. The FileUploader could be used instead (as mentioned in this somewhat related post). And of course, there are also plugins, but even without a plugin, there are a number of ways to handle images after they’re uploaded.
The first question is, what’s the desired UX? Should the user be able to replace an uploaded image with a different one? Should the user click on the image itself to replace it, or a separate button?
It’s also important to note (and perhaps you’re already aware) that removing an image from the DB doesn’t delete the actual image file. It’s still cluttering up and consuming valuable Bubble storage. DB fields of type file or image simply contain references to the file - basically, the URL. The Bubble dev must explicitly manage their Bubble file storage using the Delete an uploaded file workflow action.
You guys are right, I just needed to figure out where the background image is located in the Uploader setting. Thank you both.
Btw, for the future reference, what do you mean by this??
removing an image from the DB doesn’t delete the actual image file. It’s still cluttering up and consuming valuable Bubble storage
Delete uploaded picture don’t delete the file from the DB at all or it does but still remains? if its the later case, when does bubble delete the photo? My app is going to handle a lot of photos, and I need to know if this will cause problem for my usage.
There are 2 separate things to consider for image and file data types with regard to managing uploads :
The actual file that was uploaded to Bubble’s servers.
(This is actually Amazon storage behind the scenes - hence the “S3” in some expressions.)
The field or fields (of type image or file) in the DB which reference the uploaded file.
(Just because an image or file field is set to “empty” - i.e. has been cleared, has no value - that does not mean the actual file it once referenced has been deleted from Bubble’s servers. You must do that explicitly. Just go to the File manager tab to see if the file is still there. If you didn’t explicitly delete it, then it is still there taking up Bubble storage.)
When you, the Bubble developer, explicitly invokes the Delete an uploaded file workflow action.
If your uploads aren’t properly managed, then yes, you will burn through your Bubble storage much faster than you would otherwise for 2 reasons:
Users might upload images at resolutions (and thus file sizes) much higher than you actually need.
If your images are going to be used only for display on the web, for instance, then photos that are multi-megabyte in size are likely overkill and a waste of storage. If you’re running a fine art printing service, on the other hand, then maybe not. You have to make that call.
Images that are no longer needed but have not been deleted from Bubble storage will just be sitting there taking up valuable space.
Typically, if an image is no longer needed, then the file should be deleted from Bubble storage before the DB field is cleared (set to empty) - i.e. it’s a 2-step operation.
In short, keeping image files sensibly sized before they’re uploaded and removing them when they’re no longer needed are key to properly managing your Bubble storage. Something like Upload Buddy can help with the former, as it allows client-side (in-browser) downsampling of images files, so they upload quicker and save on storage.
