Uploading an image from the State of an element so that it can be retrieved "properly"

[major_groove]

I have built a Bubble webapp using the Worklist Template from @hackr

On the /index page is a Repeating Group showing images, that are the featured image from Projects that contain more than one image.

Now, whereas the Template demo site takes less than a couple of seconds to load, my site takes up to 40 seconds to load . When I look at the Network tab in Chrome Devtools, it shows that one or two Elastic Searches are taking 30-40s to complete.

I have not changed the design of the Index page much, and not the Repeating Group. However, I have changed how photos are uploaded in the first place. The template uses the standard Single Image uploader, which is a bit clunky for a photo sharing website, so I used the Multi-File Selector and Uploader plugin from @steven.junio91, which works fairly well.

Could the uploader somehow be responsible for slowing down the images on the homepage?

/edit a more technical friend just took a look at the network requests and said this:

I’ve looked at the network requests. The issue is that for your first few records, you’ve embedded the featured image into the database whereas for the newer ones, it’s referenced by url. I think that you might be able to fix by just deleting your first few records in the db and re-creating

Which might fit with me changing from the standard uploader to the plugin. I actually did change the way the featured images are saved now that I think about it…

[major_groove]

So, thanks to my friends message I discovered something weird - all the featured images that I uploaded seems to be referenced from the database, whereas the images that he and another tester uploaded were being referenced by URL from AWS. I just deleted all the Projects that I uploaded from the Dev version and now the Dev app loads really quickly.

I am confused why my images would be saved differently - we created these Projects all at about the same time, using the same uploader. Many of my files were ones that I had uploaded and deleted several times while testing in the dev version. Is it possible that Bubble does not actually re-upload these, and instead has them cached in the database, which is a less efficient way of retrieving them than the “new” way. Since my new users had never uploaded anything before, then their pics would be saved “properly” first time round?

[major_groove]

ok, this is weird

I just renamed all the images, and re-uploaded them as a new Project. Again, as soon as I upload any images the homepage goes back up to taking about 30s to load. When I delete my Project, then the homepage loading speed goes back to <2s.

Even when I look in the App data section in the Bubble Editor, if my Project is there, then the editor itself takes about 30s to load, if I delete my own project then the Editor loads immediately.

Any ideas? I’m baffled.

[ed727]

I don’t use images so I can’t help you, but I do recall this post from a while back in case there’s anything useful here: VERY slow load time (for 12 listings)

More generally, when you are using third party templates and plugins, it can be hard to debug things because it’s harder to know what’s causing the issue. You could try to build the functionality in a test app without the template and plugin and see if the behavior replicates.

Also I’ve found Bubble support and bug reporting to be helpful.

[major_groove]

I have asked Bubble for support. The bizarre thing, is that it only seems to be happening when I upload images myself. The images my users uploaded are the same as mine, but somehow when I upload them it screws the app up.

I think the post you link to is relevant indeed - as that seems to be what my tester discovered when looking at the network requests. However, I can’t work why it’s happening, so I guess I will have to wait on Bubble support to take a look.

[ed727]

Are you uploading the images the same way as the user, or are you putting them in via the editor in the data tab? If you are doing the exact same thing as the user (ie you have logged in as a user), that would be bizarre.

[major_groove]

Absolutely the same as the users. My first assumption was that since I was not changing the filename when I upload the files, Bubble is recognising that these files were already uploaded and were then retrieving the original files in the inefficient manner that is slowing the app down. I hadn’t realised that all the image files I previously uploaded were still there, even when I delete Projects.

I am assuming that if I change the image filename, Bubble/AWS treats it like a new image file and would handle it exactly the same as my users’. I wonder if it would be possible that AWS knows it’s the same file just with a different filename so is still handling it badly - or rather still just giving me the old files?

The new users are uploading the files only via the Multifile uploader plugin. When I uploaded the files the first few times, I was using the default Bubble single image uploader. It would be weird if the plugin was the one not causing the problems vs the default uploader.

[major_groove]

OK, now realised what the problem probably is. The original template, had a fairly laborious process whereby you had to individually upload images, including the Project’s “featured image”. I changed that to use the Multi-File uploader plugin, to upload all files at once, and changed the Featured image selection to make it an icon you click in the RepeatingGroup that shows the uploaded images and then sets a State to say that image is the FeaturedImage.

I don’t quite understand what is happening next, but it results that the Featured Image is stored… badly - whereby the regular images are stored properly.

Turns out none of my testers noticed the “set featured image” feature, and were all using the two step process (you could still upload Featured images separately).

So now I have to work out how to fix the Featured images selection feature. man, this is tough…

[keith]

Yeah, I think this was essentially austinjarts’s problem (thread linked above). They were using a very poorly documented (and probably poorly-built) template. Probably from the same people your template is from.

Here’s what I had written to austin:

" AFAICT from a quick look yesterday, the main issue here is the heaviness of your User object.

You have two image fields (Profile and Index L or similar) directly on the object. It would be better if you made a custom type “Image” - which might then have an image type field and then a text field for caption or whatever.

What you’ve done here is loaded these user pictures directly into Bubble’s storage and put them directly on the User object… OR SOMETHING. What it looks like you did is shoved the raw image data in there as a data: URL? I’m not sure how you managed to do that, but don’t do that.

Anyway, because you have these large blobs of data on the User, any time you reference a User (or as you are doing here, all Users) the data in these fields is downloaded to the browser. (And that data loading is RENDER BLOCKING.)

I tried briefly to relocate the image data to a new Image type using a workflow without success (ultimately I just did it manually). (Again, whatever process you used to attach these images is faulty.) It seems you somehow attached the image data to these Users as a data URL? (That is, I can’t find the files to delete.)

Your “Picture Index L” files for example on the 12 users shown on your home page are all PNGs and, in total, are 2.63 MB. And, again, these are shoved down to the page whenever the Users are referenced. Load time to put “Search for Users” into a List Shifter (benchmarked with Debug Buddy) showed times in the 10 to 11 seconds range.

After CLEARING (manually via the App Data tab) these image fields, this same Search takes about less than a second to load.

The [page I created here](LINK DELETED) shows the proper process for uploading and creating these images. (LINK DELETED)

(When you visit that page, hit F12 and observe the console, you’ll see debug buddy report how long the Search for Users took to execute – it’s very fast now.)

You should do as I did here: Create an Image datatype, upload your images to s3 storage and then attach the Image to a field of type Image (the custom data type, not the simple data type). (You can call this type “Picture” I suppose as that makes it clearer that we’re not talking about the basic “image” datatype, but a Thing.)

(Also, note that your uploaded images had not been resized or processed in any way. I believe your use of “:processed with imgix” is incorrect. Note that :processed with imgix CAN be used on both input and output, but note that changing the jpeg quality on output is not useful – BUBBLE PERFORMS THIS MAGIC FOR YOU AUTOMATICALLY).

:processed with imgix IS useful on image upload (e.g., to force images to a certain format when saving or to create a quickie profile image as I demonstrate on LINK DELETED.

And now, showing our images in a repeating group and a very large size is super-fast."

Now, there are other things in this project that are very wacky to me: You’re mixing up the concept of your Users and your Users’ Listings in a pretty wacky way.

But the SPEED issue you were having is to do with something really jacked up about how you uploaded your images.

FURTHER:

Your Listing (and probably other data types) has exactly the same problem, BTW, and the image fields seem to be populated by data URLs. How on earth did you ever wind up with that?

Note that when we examine this Listing object for Anonelli’s we see:

But when we click on “See” for one of these, nothing appears:

This is because these images are malformed. They are not files stored somewhere, but data URL objects.

I see you’re doing something funky with listing submission in that some intermediate object is created and then an email is sent to you.

Are you doing something manually after that to create the actual “Listing” and User profile objects? I’m at a loss for how you are ending up with these weird data URL images, but I suspect it’s something you’re doing manually somewhere, right?

And then austin replied to me with more info on how he managed to make these jacked up images in the first place – the docs from Zeroqode said to use FILE UPLOADER. Do not do this. Use an image uploader. Here’s what he had written:

I was previously uploading pictures after cropping them in photoshop for every user. This was good for the app, but bad for time management. It was taking too long to do all of that when there could be a more automated option. As part of the tutorial they showed how to make user profiles/listings. In the tutorial they say to use the “Fileuploader” to get the images on the app, and I am using the Croppie plugin to crop them. I’m relatively new to Bubble but this seems to be ground zero of where I’m running into performance problems. I see the new page you created has a much better performance, thank you!

[keith]

tl;dr: Do not use File Uploader to jam image data into an image field. What this will do is put a very large data: URL on your image and not a proper Bubble image object.

To remove these, you’ll have to use the Data tab in Bubble, inspect the objects in question, and hit the Clear field on the images you see there.

Aside: I really want to punch the developer of this particular template as I’m sure this has jacked up many new Bubble users’ projects and leads to the “BuBBle iZ sLoW” hottake.

[major_groove]

yeah, certainly looks to be the same issue. I’ve tinkered so much with the Plugin and the Template that I can’t tell now which is at fault. Also possible it’s entirely my fault (I note the demo template loads at a fine speed). I’ll investigate further and report back here with findings if/when I solve it.

[major_groove]

I’m struggling here, so what to try and explain what I have done, what I want to achieve, and where I am kinda stuck, to see if someone smarter than me might be able to help. Apologies if I repeat myself, but it helps me to re-summarise.

I started with the Worklist Template, which is basically a template to display images nicely. The template itself is fine, but the image upload was pretty clunky - it used the standard Image uploader from Bubble, but to make a multi-image Project, you had to individually upload each image, including uploading the Featured image from a separate loader. As a User Experience it was pretty bad.

So I looked for multi-upload plugins, and found the Multi-File Selector plugin from @steven.junio91. Again, I think this works out of the box more or less fine (apart from deleting), as far as I can see.

The problem I am having is getting the Multi-File Selector, to do what I want in the Worklist template to make the multiple image upload to create a Project gallery a nice experience. The main problem that is breaking this is setting one image as the Featured image (also deleting images is problematic, but that’s another issue).

The way the Multi-Selector seems to work, is that the plugin uploads the Images to the Custom State of a Plugin Element. These images are then shown in a Repeating Group. These are only like the image previews. When I click Upload, the RG’s list of images are uploaded. These are all element actions from the plugin.

When I look at these images Project object they all load fine and are accessible via a S3 URL - I click on “See” and I can see them fine.

To try and select the Featured image, I had an icon in the RG cells, and when you clicked the icon in one cell, it would set the image in that cell to be the Featured Image in the Custom State of another element.

Then when I click to Save the Project, the workflow sets the images list for the Project as the list of images that were uploaded to the Plugin element. However, the Featured image, is the image that is in the Custom State of one of the other elements.

When the Project is finally saved, this Featured image is visible - but as described by @keith above, if I click to See the image, there is nothing there. This Project will turn the homepage (which only shows featured images), from something that takes <2s to load, to something that takes 20-40s to load.

So far, the only way I can get the thing to work with the Featured image to work is to remove the ability to select a featured image - I just make the Featured image be the first file that was uploaded to the Plugin element’s customer state.

Ideally, I would like a user to still be able to select a Featured image. I’d also like them to be able to delete images that they have "pre"uploaded (before the full import). If I am forced to stick with the “first image is featured image” compromise, then it would be nice to be able to re-order them… but that seems like fantasy-land at the moment.

Does that make sense to anyone, and if so would anyone have any idea what I should do? I’d be very grateful!