Images keep disappearing

Recently I have been experiencing the annoying problem of images disappearing from the database. I get errors similar to this:-
General warning
The image could not be loaded: https://d1muf25xaso8hp.cloudfront.net/https%3A%2F%2Fd97a4f17e452f3ee7cd1a70c6f50dee0.cdn.bubble.io%2Ff1710431128943x842880337012626600%2Fimage.jpg?w=1024&h=&auto=compress&dpr=1&fit=max .

Looking through previous forum posts, it seems that this has occurred on many occasions in the past. I have forwarded a bug report and hope that they can permanently resolve the issue.

Are the images attached to a database entity - i.e. are they private - or are they intended to be publicly viewable?

I ask because I get a 403 when I attempt to view the image, and that indicates access is not allowed.

Also FWIW, it’s basically just the URL that’s stored in the DB. The actual image data is in Bubble file storage (which is AWS behind the scenes); so based on your description, it doesn’t seem that anything is disappearing from the database.

The image is attached to a database entity, so you will not be able to see it by clicking the link I have posted. I understand that the URL is stored in the database and not the image. It appears that the URL no longer fetches the image from AWS storage to be displayed.

In that case, the file URL should look something like…

https://my-app.bubbleapps.io/version-test/fileupload/f1713800632499x867567073856659000/my-image.jpg

Note the “fileupload” portion of the URL. This is a special URL that Bubble generates for private files. That’s how Bubble controls access to them. Private files cannot be accessed directly on AWS or via Imgix (the image-optimizing CDN that Bubble uses for public images).

Private files can be accessed only through this “special” URL, and it should be the URL you see when accessing the URL property of a private image…

Anyway, that’s the gist of how images are handled in Bubble. Might need more detail or context to help further.

Thanks for your guidance, but I cannot understand why the following URLs give different results when retrieveed from the database in the same Repeating Group.

d1muf25xaso8hp.cloudfront.net/https%3A%2F%2Fd97a4f17e452f3ee7cd1a70c6f50dee0.cdn.bubble.io%2Ff1710838674735x608552114163038100%2Fnative-camera-file.jpeg?w=1024&h=&auto=compress&dpr=1&fit=max .

I might add that they are images captured using the Native Camera plugin. When the image is saved, the URL is passed to the database. This has been working well for most database entries, including this one, but I’m getting random URLs to images suddenly not working. The vast majority of the links in this database are ok.

I know nothing about that third-party plug-in, but you’d have to share some screenshots of your setup - i.e. the workflow and action that’s actually saving the images - to enable others to help you troubleshoot. Simply posting URLs does not provide sufficient information or context.

Also, I thought you said the uploaded images were private, and yet the URLs you posted are those of Imgix, the image-optimizing CDN Bubble uses for publicly hosted images.

Anyway, at this point, the issue might be a bug, might be the plug-in, or might be your Bubble logic. There’s really no way to tell without additional details or context.

Thank you for your guidance. I’m sorry about my confusion about the privacy of the images. Clearly you understand more than I about how images are stored by Bubble.
There is nothing wrong with the plugin, it works perfectly well in capturing and storing the images. If there was a problem with the logic, none of the images would display. Indeed, the images that are now missing were rendered many times before the error popped up.
Looking back through other posts on the forum, I see many instances of this problem occurring. It appears that this is a serious bug which can cripple an application and it seems that Bubble are not getting to grips with it.

If you’re convinced it’s a bug, then by all means, submit a formal bug report. Be aware, however, that if it’s not reliably reproducible, it’s not likely to get fixed any time soon.

FWIW, I can imagine how that could happen IF, for example, the on-page (i.e. Imgix-generated) URL was somehow being saved and reused, because Imgix periodically expires its image caches and regenerates the image URLs.

I’m not saying that’s what’s happening in your case. I’m just saying it’s conceivable to me how it could happen IF one were not always referencing images and URLs only through the built-in Bubble image type.

2 Likes

I can confirm a same thing happening to me. Images, seem at random, to break, not display in DB, plus the link throws 403/access denied error. Images aren’t private and uploaded using Bubble’s own upload elements. Submitted a bug report.

1 Like

I am fairly new to Bubble and I think I may be experiencing what you’re describing here. My issue may be that I don’t understand what I’m actually saving to my database (when I thought I was saving actual images.)

I filed a bug report (they are investigating but “this team is currently experiencing an increased volume of requests”) and requested help on the forums here: Random images broken in database? before I found this thread.

Can anyone help me understand how to make sure I’m actually saving images to my database rather than just a link to an image that’s stored somewhere else that I can’t actually save? In my workflows, the expressions I’m using say (on mouse over) they evaluate to an image, as shown here:

image

By way of overview…

Go to Data —> File manager to view a list of all files that have been uploaded to your Bubble cloud storage. Think of storage as a big hard drive where the actual files are stored. File storage is not the same as the database.

The image and file data types represent the file. When you save a thing of type image or file to the database, you’re essentially saving a reference to the actual file.

The distinction between storage and DB is important because removing an image or file from the database does not delete the file from storage. Similarly, deleting a file from storage does not remove the reference from the database.

It’s also worth noting that Bubble has a seamless integration with a service that works in the background to automatically optimize images, so what you see on the rendered page is a web-optimized variant of the originally uploaded image.

Anyway, that’s a brief synopsis of the way image handling works. It’ll be interesting to hear from Support as to whether there’s an actual bug or not. (Much more detail than what’s been provided here would be required to make such an assessment.)

1 Like

Thank you for taking the time to explain this! It makes sense, and makes me think that at least I may not be experiencing a bug but rather have been saving my images incorrectly.

Is there a step I can add to my expressions in the workflows to save those images to the File Manager rather than just the reference?

Whenever you upload a file, it’s automatically saved to storage and appears in the File manager. (You can easily test it. Just upload a file and refresh the File manager page.) When you save an image or file to the DB, that saves a reference to the already-uploaded file.

If you wish to expunge a file completely, then in addition to removing any references from the DB, you must explicitly invoke the Delete a file action to remove it from storage. Then it will disappear from the File manager.

Thanks again for your help. The way I am “saving” images to the database (shown above) does not appear to simultaneously save them to File Manager though. I have over 525 images referenced in my database, but only 102 in the File Manager.

How are they being uploaded? As I said, files (including images) automatically wind up in the File manager when uploaded - i.e. that’s where they’re uploaded to. That happens (or should happen) regardless of whether or not a reference is saved to the DB.

EDIT

Just wanted to note that it’s possible for the DB to contain more than one reference to the same image. Whether it makes sense to do that depends on the nature of your application. A one-to-one correspondence is probably much more common though.

I am using a Zeroqode plugin to get an image from an input link’s URL Preview (metadata), then creating a new thing (a post) and assigning that image to the new post’s image field in the database.

What I think I’m gathering is that this is actually only a reference, not an image. I am not using an uploader.

[s] Do you think appending “:processed with Imgix” or “:saved to S3” or “:encoded in base 64” to my expression would actually save it?

Any information on what each of these operators do would be greatly appreciated. I think I’d have to set up AWS S3 for the “:saved to S3” option to do anything, is that right? [s]

Editing (again) to say, I think maybe I don’t actually want to be saving all these images to the database (they are definitely one-to-one references, not more than one to the same image) as thumbnail images are a key component of my app.

Maybe what I really ought to do is refresh the link when an image reference goes dead, but that sounds very advanced. Anyone able to give me a hint where to start?

1 Like

I know nothing about the 3rd-party plugin you’re using. Nor do I understand the details or context around what you’re wanting to accomplish. My comments were intended only to provide an overview of Bubble’s built-in image handling and uploading.

Unless someone else on the forum can jump in to assist, your best bet might be to read the Bubble docs, consult the documentation for your plugin, and/or contact the plugin developer for assistance. Good luck.

Thank you anyway. I’ve posted on the Zeroqode forum too, but I don’t think it’s a function of the plugin, but rather how images are saved from any third party (rather than being uploaded directly through the Bubble uploader element).

Ah, ok. In that case, the :saved to S3 might be what you need. It “pulls” an image from an external source - i.e. hosted elsewhere - and saves it to Bubble storage (which is AWS S3). Again, that’s described in the Bubble docs I referenced.

1 Like