Not sure if that’s the right terminology but I’m seeking a way to programmatically access the URL of a user’s public profile so I can use it in emails, social media share widgets, etc. This vid shows what I’m trying to accomplish:
I found this feature request so presumably the answer is no but just curious how others would handle this issue. It’s possible to manually hit each URL and then copy that into a field in the User table but are there issues then with session sharing (assuming the URL’s are all dynamically generated and unique to the individual)? Any ideas?
@ashley thanks and yes understood but just to be clear it’s not really “friendly URL’s” that is the crux of my issue though. I need a way to definitively know the link for a user’s profile so I can include that in emails and make social media sharing buttons in their dashboard so they can share the profile.
I would be fine with a long, ugly URL as long as there’s a way for the app to reliably know what that is for each user. You can solve this at the same time you solve friendly URL’s but this is basically a caveat to that in that it would need to include “magic text” for being able to define where passed data lives in the URL. Here is an example of how it might work in my situation:
@grid7 the userid itself is corresponds to the row in the users collection. The URL, though, uses an encoded version of that. It’s possible you might be able to grab that by looking at the referring url when you send the user to a webview, and then save that back as a property on the user…
thanks @Ben so lemme make sure I understand what you’re suggesting:
Create an “interstitial” page between the list and the details page that serves to grab the encoded value in the URL and store as a property in the User collection
That value can then be later used to generate the direct link to the user’s profile page by combining the base portion of the URL for the user details screen with the variable portion that is unique to the user
You would still need to either manually click through each profile after new user creation or setup an automated process to spider each page of the user directory periodically if I’m understanding it correctly… but yea that is good to know about how the URL is derived.
@Fafa this is over a year now unsolved- I don’t see Adalo creating a component to solve this anytime soon.
I submitted it to Adastacks here: Adastacks | Roadmap I think it’s more likely a 3rd party like them will come up with a solution before Adalo does. If you want to vote it up search that for “deterministic” and give it your vote so @pford prioritizes it.
If you want users to have their own ID, you could make them sign in move them to a “Loading screen” then use randomizer component and make sure it updates Logged-In User and say from which number to which! and then you have your user to have their IDs!
It doesn’t have to do with creating unique ID’s. It’s about being able to deep link to listings in the app by passing their ID in the URL. This is a desperately-needed feature of Adalo and I just suggested that given the amount of time which has elapsed with no movement on this front that the solution is more likely to come from a 3rd party than Adalo at this point, hence my link to the Adastacks roadmap and recommendation to upvote there.
Sort of. There are actually 2 separate deficiencies here that are being conflated into one. Let me tease these apart to clarify:
yes there is no short friendly URL capability yet but that’s actually not a blocker. You can shorten URL’s after the fact. Bit.ly for instance has a developer API so if you could reliably get a deterministic URL that resolved to your user’s unique listing you could post-process it via an API call that ran it through Bitly and converted it to a short URL which you then store in the collection with the user record. No problemo. That though would necessitate an absent prerequisite feature here which is…
There is currently no way to dynamically supply a userID (or any ID) and have it populate a listing page with the details of that collection item. I’d be fine with a long gnarly URL as long as it can be generated predictably and resolve to the appropriate listing page in the app. Unfortunately there’s no way I’m aware of currently to do this and it’s a huge blocker because it prevents you from doing simple things like:
Sending emails that have a link to the user’s profile
Generating social share links which bring visitors to the user’s page
Enabling impulse buys for specific items for visitors coming from outside the app
I realize Adalo is more focused on being a mobile app generator platform vs. prioritizing web app functionality but right now all the use cases for deep-linking external visitors to a dynamically-generated listing page are precluded so I’m now going down the path of setting up a Webflow app that uses the Adalo API to access the collections and expose listing pages that way. IMO this is important enough functionality that it deserves to be native within the Adalo platform but it doesn’t seem to be high on the priority list so my best hope here is that we can bend the ear of people like @pford who are actively solving deficiencies like these via 3rd party bolt-on components. This is IMO an important one to solve.
@grid7 I’m also looking after this deficiency since a while ago… I definitely agree that this has to be a native feature for sharing content from the app to the world haha. There’s not a properly working solution for just sharing something on the app to a friend through Whatsapp or Facebook, even if you have both Web and Mobile sharing databases. Thus whatever you build becomes behind walls. There were two different components trying to solve this case. Neither of them works now.
I think there is misinformation and the requests are floating around with different stories on Canny. People have various ways to tell what they are trying to achieve but they are all so similar! If you quickly skimmed through these requests and the comments below… They need to be consolidated. It would then rank in top 5 on the backlog. Please have a look @Ben