Debate: Create and edit new thing. Single vs multiple pages

Thanks for the input, @boston85719.

As soon as a file/image is uploaded, it’s consuming space on Bubble’s AWS storage (and thus your Bubble account) even though it is NOT yet associated with any “Thing” in the DB.

Despite being able to view it in the file manager, there’s no way (using actions or otherwise) to get a reference to the file if it’s not associated with something in the DB, which it’s not immediately upon upload. IOW, there’s no way to simply get a list of files uploaded by a user.

I didn’t experiment with auto-binding, so perhaps I’ll explore that option and consider its impacts on my desired UX.

But the abandoned uploaded image(s) remain, taking up account storage. I understand that custom states are client-side and ephemeral, but an uploaded file does not get deleted just because a custom state no longer exists.

I was not planning to use auto-binding, but I might tinker with it a bit to see if it simplifies file management while not adversely impacting the UX. Thanks again for sharing your thoughts.

That’s true, but Bubble currently does not expose any way to list files (let alone filter them by “creator”) - thereby potentially leading to “effectively orphaned” files.

In short, Bubble file management capabilities currently leave much to be desired - especially if your app is file/image-centric. :frowning_face:

I didn’t realize there was a way it was saving it to your storage in file manager as soon as it is uploaded…I always assumed if it wasn’t in my DB it wasn’t uploaded and taking up space. This is new to me and good information to be aware of when setting up file/image uploads.

I would think then that a way to mitigate the issues is to always ensure there is a “thing” that uploaded images/files get saved to immediately…perhaps creating a data type of “uploads” and have it saved there upon upload…but I still am under the impression that creating a workflow to save it to a thing or auto bind as soon as an image or file is uploaded ( ie: uploader value is changed ) is the best way to do it…and having the status on that thing set to “draft”

Because at the end of the day, when would you put an image or file uploader onto a page that doesn’t have a specific purpose ( ie: intention to be saved to a specific data type )

So if it is abandoned, and you don’t want the changes to be saved unless they press a “save” button, the custom state idea I mentioned is still to me the way to go, because you could always put an API workflow together to “clean up” your app each day by searching for any “thing” that was changed that day…In this case I’d put a second file or image data field onto the data type that would be “edited image” and my search would be for any thing changed today that has a status of draft and edited image is not empty.

This assumes that when a user is going to the edit page you create a workflow upon page load or whatever button they press to trigger the edit to change the data types status to draft.

That’s basically what was suggested in the thread I referenced. However, I prefer my approach; but I think I’ll implement @mattb’s proposed technique, as that would help “randomize” the clean-up and thus more evenly distribute server load.

Yes but what happens when the user abandons your app completely…when would you get a chance to run a page load workflow to clean up the draft if the user never returns to log into the dashboard?

I think the scheduled workflow that was provided in the thread you referenced is the preferred method to ensure you can actually “clean up” the app completely.

In the idea of server load time, schedule it so it occurs when you have the least traffic on your app.

Definitely not the case. (Judging from comments in the forums, I think lots of folks confuse a “reference” to the file (basically the URL) with the file contents itself.

For my particular app, inactive/dormant accounts will be flagged and eventually deleted, so not an issue. Of course, a scheduled workflow is a valid technique to have available in one’s toolbox - just not the best approach for my particular situation.

What is the “attached to” in the file manager supposed to reference?

because the image noun_tar for instance was uploaded and saved as an image of a data field on a data type.

Seems like it should be referencing a data type if it was saved to a data type…all of my images have a blank attached to.

Also, if the attached to is supposed to be referencing a data type, then I think a good idea would be for bubble to enable a workflow to search the file manager for any file with “attached to” as blank…that could probably speed up the “clean up” workflow.

That’s a privacy related feature. It means the file is not “public”. Only those who can see the “object” to which it’s attached can see the file. See the reference.

It’s super handy when you want to allow only limited access to certain files, but it’s definitely not what you want for most files on a public file sharing platform.

1 Like

This is interesting and certainly something to test out. One of my issues with autobinding has always been undoing what was done but it never occurred to me to copy the thing before editing it.

Really great thread, guys. You are making me rethink some of my methods :slight_smile:


…and @sudsy
I’m thinking it would probably cover all basis to have a scheduled API call to remove these entries, plus a workflow to remove entries when a user hits a particular page.

In my case, the user will see these things [jobs] on their dashboard. Rather than displaying empty /incomplete Job entries, these can be cleared on page load so the user doesn’t see them.

If the user doesn’t hit the dashboard page with 24 hours, the scheduled API call will remove these and tidy up the DB.


I’ve spent some time building my image uploader, and will be using same techniques for file uploader. Unfortunately I am at this point not using the multi-file uploader, but instead using the single picture uploader.

Some issues that were mentioned in this thread about files uploaded automatically and being stuck in the file manager taking up space, I found some solutions for some scenarios.

Currently I am limiting the file size of an image, this will help with pricing the app for various plans and the corresponding storage capacity. My workflows have some conditionals to automatically delete files that are larger than the maximum allowed.

See this post

Then from there I wanted to give the user the ability to also “delete” the file from the database and file manager after they uploaded it.


What I needed to do in workflow was to delete the image using a url (bubble default operation) to delete it from the file manager. To ensure I could reference the right URL for the image I had saved it as a data field on the image data type in my D.B.


I believe using this strategy should help with some files uploaded to the file manager that are not wanted. Although I don’t think it is very helpful in case the session is lost somehow, but having the file saved to the D.B. upon upload with a URL as a data field should help make it easier to set up an API workflow on a list of files/images with status “draft” so you could create the list of all files status=draft and delete the files referencing each items link.

@sudsy do you think this set up would work out in the long run? Any ideas of how to improve or places it is shoddy?

At this point I am trying to carefully consider the impact of file uploads on my storage costs as I want to have my app image/file heavy but limit users abilities based on pricing tiers. I wasn’t aware of the file manager upload prior to this thread.

Yeah, same here.

In my app, I cap the number of products per user as well as the number of images per product. I also constrain the file size (in bytes, not pixel dimensions) before upload.

I haven’t tried your approach, but it seems sound. I think the key is either deleting or storing a reference immediately upon upload. As long as you have a reference, then it can be used for clean-up / deletion - whether it’s by the user explicitly or via an automated workflow.

1 Like

Lovely debate!

My app is one massive page with 40+ reusable elements. Some for data entry, some for data display. I use the same popup RE for creation and editing, and handle empty items as I see fit depending on what the item type is.

You can probably pop up the edit window with no Thing attached and in your save workflow detect if your popup has a Thing or not, and then either create or update accordingly… But I’ve never actually tried that (but this post has made me curious about giving it a go…)

I have exit on click outside turned off for my popup as that is confusing to the user. Sometimes I use the On Close event to execute a save. My save action(s) are always in a custom workflow so I can access them from different user actions if needed.

After a lot of experimentation, I moved away from auto binding. When the database access is being throttled, the slow database update makes for a very confusing user experience. I now only use it for yes/no switches here and there which gives quite consistent results.

Good luck @mattb!

1 Like

Thanks for contributing, and I like the sound of these new ideas.

I’ve decided to stick with auto binding right, mainly because I’m tabbing through data entries and only saving a maximum of two fields per tab. Updates are completing in less than 2 seconds which is adequate for my app.

1 Like

I believe the way to do it would be to use a custom state on the reusable element. the custom state on the reusable element will be set to the “thing” for that particular reusable element and the custom state would be set after first “creating a new thing” in the D.B. and then passing that “thing” to the reusable element by setting it’s custom state to that thing. That way you can also reference the “thing” in the reusable element on the page itself.

When you say “throttled” are you saying a lot of users are on the site and accessing / writing to the database at the same time? From all the tests I have done ( all with me as the only app user ) my experience was that auto bind saved things to the database much quicker than a workflow event would. In fact I wouldn’t usually even see a progress bar update with a auto bind and sometimes needed to put a message for “successful upload” to help users understand the information was saved to the D.B.