I am using a series of url parameters to store values for filtering data. Works like a charm, but I pre-empted the possibility to enable passing of slugs instead of uniqueIDs as the parameter values, when my filters are database “Things”.
From everything I’ve read, slug should work just like Unique id when bubble parses the URL parameters. However, switching to slugs seems to result in my workflows or conditionals using “get data from url” ending up blank.
Maybe I’m mistaken and url parameters for database “Things” can only be retrieved via uniqueID? (…unlike path segments, which Bubble parses automatically)
Here’s how I pre-empted the ability to use slugs, if they exist later. I pass the slug as the URL parameter value, but default to UID (…when slug is blank. this all works fine to get the URL as I want it).
My understanding is that this should parse/retrieve the “Thing” regardless of whether it’s the UID or slug. Here’s a screenshot to show into the config for the get ba from url expression:
Works fine if the param is set to the uniqueID, but anywhere I use “get data from URL”, it’s pulling an empty record when the URL contains the slug instead of the UID.
So Bubblers… do I need to ditch this idea and only support UIDs in my URL parameters? Or am I doing something wrong? If workaround is to switch from “get data” and use “do a search for” where I use constraint slug = filter dropdown value's slug… I’ll almost certainly pass for performance reasons unless I can be convinced otherwise.
You’re right that “get data from url” with slugs doesn’t work the same way as path segments. I’ve hit this exact limitation before.
The problem is that “get data from url” only supports unique IDs, not slugs. Path segments (like /thing/test-area) support slugs automatically, but URL parameters (like ?ba=test-area) don’t.
Your workaround approach makes sense, but here’s what I’d recommend instead:
Option 1: Use “Do a search for” instead of “get data from url”
Instead of trying to force “get data from url” to work with slugs, use this pattern:
text
Do a search for Budget Area - Add constraint: slug = Get ba from page URL (as text) :first item
This works perfectly with slugs and is actually more flexible. Yes, it’s technically a database call, but Bubble caches aggressively so performance impact is minimal for most use cases.
Option 2: Stick with unique IDs in URL params
If performance is critical and you’re filtering multiple things, using unique IDs in URL parameters is actually the standard approach. Most production Bubble apps use UIDs in params for exactly this reason - they’re guaranteed unique and work natively with “get data from url”.
Use slugs for your path segments (for SEO and clean URLs), but UIDs for parameters. So something like:
/area/test-area?filter=123456789x123456789
The slug approach with “do a search for” will work fine unless you’re doing this on every page load with thousands of users hitting it simultaneously.
The AI explanation above is correct, but there’s also a third option it didn’t mention that is easier.
If the page you’re going to is set up with a type of content, and you send the actual thing using the go to page…
Data to send = this thing, then Bubble handles everything automatically. It decides whether to use the slug or the UID in the URL, and it loads the Thing without needing a search or URL parameters at all.
So if you don’t need the value specifically in a parameter, configuring the destination page properly lets Bubble do all the slug/UID work for you.
True, but it wont enable something like get data path list - data type x item#2 from url, or data type x item#3 from url, thus when using some sort of filtering and addition you will need to make them as option sets.
I was talking about the case where you don’t need to pull specific items out of a path list, just the normal go to page, send the thing setup. In that scenario, Bubble handles the slug/UID automatically, so you don’t have to deal with params or option sets at all.
But this guy is working on filters, so filtering based on data type using path list he is trying to do. I am telling in advance that he won’t be able to do that unless the path is option set items, meaning budget areas needs to be option set item.
You are mixing it up by assuming click and go to new page thing.
What the guy needs to do is followwing
option set
attribute1 display bugdet_area,
attribute2 ba item and you will by hand manually add that to option set
and when you are doing go to page, send ba display, and get data fromo page url option set item’s ba_item, and you will ignore empty constraints, that way, example.com/ will not filter and example.com/new_york, both will give different resuults
And vice versa, lets say your user picked New York, when filtering you will need to pass go to page- option set (holder of new york)’s url, and that is corresponding to newyork for url compatibility.
You will need to create 1 option set to get url 1 option set to pass that url.
Or you will not use path-list, lose SEO and use parameters.
You’re trying to go to bubble advanced theory 9000…
you’re talking about the path as list SEO setup. That’s a totally different structure than what I was referring to.
My comment was just about the normal case where someone sends a thing to a page using go to page data to send, which doesn’t involve path lists or option sets at all.
So yeah, we’re talking about two different approaches
I appreciate the solve for filtering data - paths don’t really make sense because I’m filtering down results of a repeating group on a page with complex display and summary of the (filtered) data type in question. I believe paths would require building out replicate pages for every different “Thing” type field that I’m filtering my main records with.
That being said, I also can’t go the option set route, because my filter records are created by the user. Budget areas (and 5 other filter criteria) are freely created records by users in their projects, personally named for their needs. They can then be assigned to the records of my RG data, and can then be filtered.
Apologies that these requirements were unclear! But this is helpful because I’m able to make the decision to stick to UIDs - SEO doesn’t matter, I just wanted to shorten & prettify the URL for bookmarking, sharing links to collaborators, etc and slugs just made sense if they were handled like UIDs.
I might try out the “search for” with slug = constraint, sometime down the road if there’s pushback with the URL length. But seems unnecessary for now. I just need to roll back my feature that swaps slug into the parameter if it exists, because it breaks my filter/“get data” retrieval.
