While I’m building the page, using the default parameter value, this works fine; data is returned and the page displays as expected. However, when the page is published and I try to use the same parameter value, i.e.
We have a video here on how to create dynamic collection pages that might help but can you tell us a little bit more about your use case and what you’re trying to achieve?
For example:
what does the 80ab3... value correspond to? Is that the UUID of the record in Supabase?
how does the user arrive on the page with the dynamic URL?
in your screenshot, you’re showing the default value used in the editor. How do you update that value and fetch the correct record?
have you tested in preview mode in the editor that it works no matter what item you select?
Don’t hesitate to share a short video walking us through what you’re trying to do. It’s often easier to understand and help that way.
I have the exact same issue on my side. In the editor mode (with the default value) it works fine but as soon as I publish the app it’s not working. I already created a bug ticket as I think this is an issue with a UUID as a page pararameter (bug report title: Published page with parameter returns 404). I have other page, which is using url parameters and there it works just fine (the parameter is not formatted as a UUID).
As some background info @Joyce (at least for my project):
Yes, it’s a UUID for a specific record in Supabase.
In my case, the user would always land from an email on this page
In my case, the default value is just for testing. In production the url will always be concatenated by the backend when sending out the email (with the correct UUID as the parameter) and then to fetch the correct data a page workflow is triggered on page load.
@Joyce have you gotten any info from the tech team regarding timeline? Plan was to showcase my app beginning of next week to stakeholders of the project and this would be a part I wouldn’t like to let out in the presentation.
I was able to reproduce the bug on my own projects, comparing collection pages with ids (works) vs uuids (doesn’t work)
the weird thing is, if you click on an item in a collection list page, it works fine even with UUIDs but not if you land on the page directly (like your use cases with users clicking on a link in an email)
the tech team thinks it’s a bug that can’t handle the fact that the UUIDs in the URL parameter include dashes (i.e. -)
we don’t have a bug fix yet, nor a clear ETA
As the go-live of your apps approach, I can offer 2 workarounds while we work on a fix:
create a new column in your Supabase table that formats the UUIDs to remove the dashes and use that column value as a URL parameter in WeWeb (so it’s still more random and secure than sequential ids)
use no-code formulas in WeWeb to remove the dashes from the UUIDs when binding the URL parameter variable but adding them back when filtering the collection
I think option 1 would be the most straightforward, easiest to maintain approach but I’m not sure how to do this in Supabase. There’s probably a function you can write but maybe exporting the table in a CSV, adding a column, and re-importing the CSV would be the easiest way to set this up (but then new records would not have that new column value so depends on your use case :/)
Sorry about this. I know it’s not ideal but hopefully it allows you to move forward. Let me know if not. In the meantime, we’ll keep working on a bug fix.
Thank you for the update! This definitely works as a hotfix I already set it up as a mix of the two approaches (striping away the dashes when building the email links) and then re-adding them on page load on weweb in a variable, which is based on the page parameter.
I already set it up as a mix of the two approaches (striping away the dashes when building the email links) and then re-adding them on page load on weweb in a variable, which is based on the page parameter.
