I’m creating a user profile, I want my user to be able to upload a logo.
I’m using a supabase bucket to store the image. So far, uploading the image works fine.
I’ll second this. I am also getting the render/image directory when trying to fetch publicURL.
I could do a workaround, but if this is a bug or there’s another way, I’d prefer that.
I definitely believe it is a bug that I’ve been dealing with for months since it won’t allow you to view pdfs in the browser. The workaround that I’ve been using has been to use custom JavaScript to call the supabase plugin to get the correct public URL (Displaying an image from Supabase - #12 by Broberto).
const { data } = await wwLib.wwPlugins.supabase.instance
.storage
.from('<bucket-name>')
.getPublicUrl('folder/avatar1.png')
return data
The URL return from this matches what you see if you manually get it inside supabase.
I honestly might just continue doing this as so far is covers all files types (and I don’t use the transform or download link that often anyways), but it would be nice for them to fix this issue with the plugin.
So far, I’ve been using the GetSignedURL method instead. It’s not ideal and you need to either cache images or call the DB often to retrieve them. Since my app is not image intensive it’s been ok. But, your workaround seems like the better solution. I will test it. Thank you
UPDATE : It works great !
I created a global workflow in weweb to house the custom code proposed by @avery. Sending the filepath in parameter and it works pretty much like the API would.
Ok that’s interesting, it seems like when using transform: false in the sdk action as parameter it still build a specific url related to a transform API, even if there is no parameters provided to ask for a transformation.
We will test to remove the transform property itself from the sdk call when every option are disabled and see if it solve the issue.
Thanks for sharing your findings there, it helped a lot
Didn’t think of this. I guess it’s a good method for a temporary workaround, but the problem with this is maintenance down the road. If at some point the API changes and/or start using another pathname (which happens all the time), all your links will stop working and you’ll have bugs to fix across your code. I would rather avoid maintenance and potential bugs while my app is improving and scaling up.