Thank you, @boston85719 for a super-helpful post. The steer to the Crop Upload Image plugin was invaluable for cleaning things up here.
I thought I would add a finding, as I found Bubble’s handling of images a mysterious process.
I wanted to keep the files stored on Amazon to an absolute minimum, so I thought I would see what happens if you save the image to Bubble’s DB and then remove the file from AWS in the workflows using workflow action Data (things) > Delete an uploaded file > image URL. (This is full-on, guerilla space-saving.) To my surprise, it seemed to work. You can delete the Amazon file in a workflow after saving it to the BD, and the image will show in the app. Result! This offered the possibility of never having dead files in AWS storage. It bugs me that I can’t tell which images are used in the app and what was deadwood. Read on.
I said it worked … But only for a couple of days or so. The problem is that after a while, nothing appeared in the user’s profile when using the app. The DB record said it had ‘something’ - it did not behave as if the image was empty. I have conditions to show a default image if the user did not submit a profile image, and they were not being actioned. So I had a load of blanks appearing in the app.
It seems as though there is some sort of routine housekeeping on Bubble’s side that checks the link between the database and Amazon. It sweeps the database of content using what’s on AWS as the clue to whether it should throw some sort of switch in the DB or not. But it does not empty the database entry completely, so any ‘is empty’ clause would not work.
Moving on, I now remove the old file, when a new one is saved to replace it. I do this, when saving a CropUpload.
On the subject of cleaning out redundant images on Amazon, it would help to get an index of all the files from AWS that belong to the app, so a reconciliation could be done with what’s in an app, to reveal those with no links in Bubble. I have no idea if this is possible.