Dynamic Links - pretty URLs

dear @emmanuel & @Bubble team
i wanted to ask you consider a feature that perhaps is very easy to implement but might have big implications for many users.

how about adding an option to disable 404 redirect for non-existing pages (so that request comes to the landing page without a redirect) or change the redirect page to something else (with an option to capture the path and forward it)
That way we’d be able to use dynamic links in this format mydomain.com/dynamiclink
similar to facebook.com/johndoe or instagram.com/jewelstoreboston

right now it’s possible to achieve that only if it’s a tier 2 link (for example mydomain.com/id/dynamiclink)

UPDATE: we have found a solution and posted it here: Pretty URLs with Dynamic Links - mydomain.com/dynamiclink - Solution from Zeroqode


That would be kind of cool. Couldn’t you just set up (on the 404 page) a “Navigate to Page” workflow on “Page Load”?

I’m pretty sure the Sudsy plugin can do this?

1 Like

Yes, a dynamic homepage would be great!

A dynamic home page is already SORT OF possible. In other words, if you include “index” in the URL, it actually works as desired. Of course, the URL is no longer “pretty”. What that suggests, though, is that perhaps all that’s needed is some tweaking of the router logic for handling home page requests. The logic would be something like…

When the homepage is visited and “index” is NOT in the URL, make “index” what appears after the first slash (if “index” is not present) OR What appears after “index/“ (if present) available as the Bubble “Path” anyway.

It seems like that’s all it would take. :grin:

(Being able to change the redirect page would probably not be the ideal solution, however, without also being able to change the underlying HTTP response code.)

Unfortunately, no it can’t - not for the home (index) page. :confused: It must be an internal page.

1 Like

Doesn’t seem like this approach would break anything either. :slightly_smiling_face:

Maybe a new workflow exception event would be useful too in order to control what happens when no “resource” is found.

once Bubble redirects to 404 the requested URL is lost, so there is no way to capture what was after mydomain.com


there is no way to configure any logic, because Bubble won’t get to the index page if request is made to a non-existent page, It would simply be redirected to 404. It might work with mydomain.com/index/dynamiclink, but i already said that yes, it’s possible to have a tier 2 dynamic link with any other page (like id or ref etc.) but that’s not a very pretty link then.

the workflows of index page won’t run because Bubble won’t load the index page at all, Bubble will think the requested page doesn’t exist and will route to 404

1 Like

Yes, that’s the way it works now. What I’m suggesting is a change to the router logic which would, instead of redirecting, simply serve the index page and set the Bubble “Path” accordingly.

Bubble obviously knows when a non-existent page is being requested, and a “non-existent page” simply means the “site root” with a “Path” that doesn’t correspond to an actual Bubble page. Seems it should be possible (if not straightforward) to just change that logic to 1) serve the index page, and 2) set the “Path”.

Of course, I have no “inside knowledge” of Bubble’s router implementation, but all I’m saying is that it seems quite doable in the router logic.

EDIT: To clarify… By “router logic”, I don’t mean Bubble WF logic; I mean the actual router logic implemented by the Bubble platform (presumably in Node JS or whatever’s being used server-side).

oh that’s right, sorry i misunderstood this initially.

1 Like

No worries. Hopefully, the Bubble folks deem it feasible. And I like your idea of it being an option.

1 Like

hey @duke.severn
i don’t know why you withdrew your message but your solution actually works :slight_smile: it’s a bit hacky but not to the extent that one wouldn’t use it…

I totally missed the fact, that Bubble doesn’t change the requested URL path to 404 so it’s easy to configure a workflow on 404 page and redirect where required.

I repost your original message for others to see.

I> politely disagree. I actually made a video about it back in December. I just retested and it seems to still be the case… This is the best workaround I’ve found for the time being. But I’m +1ing this idea because the method I outline in the video is hacky and could potentially be very slow if you have a ton of users.

Oh is this still true if the app is live on a custom domain? I guess that’s what you meant.

@nicpagonis, you were right too.

But if it’s easy for Bubble to add some native options to manage the redirects that would make it more reliable.

1 Like

Yay, I’m right! First time in a while. Feels good to be helping other members of the community.

1 Like

I’ve just tried that solution, it works, but it’s quite slow, the user gets to land on a page for 1-2 seconds and only then is redirected to another page

True. I forgot to mention that we would need a new category of workflows that are not bound to pages and that are ran before any page is loaded.

I’ve always found that having all WFs(except API) linked to pages is quite limitating as we can’t build a proper access and routing model.

1 Like

no yay. you lose access to the browser back button.

Correct on both counts. Revisiting it after the post and doing a bit more testing, I decided it was too hacky to want to put it up as an option. I didn’t really want to push new users to try it and then think Bubble was slow or bad or whatever, not understanding the implications of the method. Your reposting of my removed message is a bit of a breach of confidence, but whatever, I guess I should’ve had all those thoughts before pressing send and that’s on me.

If your database is not large, it works. It will work for pages like “support” and “login”. But I would no longer would recommend using it for user pages or any “thing” with more than a few entries. Apparently putting it on apps where the database has many “things” is also slowing it down? That’s by feel not testing (disclaimer). Allright I hope that answers the question “I don’t know why you withdrew your message”.

Also @danielowega you’re right, but UX-wise, I mean, pretty inconsequential. Who would navigate to a custom url from a page they want to go back to. CTRL+T then add URL is what most people do. Otherwise you got wherever you are from a link and DO OBVIF_(*OUSLY NOT use those urls for navigation from within the app… So back button is probably not an issue here, even if Bubble opts to do redirects that way.

Now @ Bubble. When I first opened this forum this was a discussion I was interested in. That was 2 years ago and I know you said it was difficult for your infrastructure to support such a change. Seems to be a pretty hot topic, and I’ve seen firsthand how you listen to your users. Looking forward to seeing this implemented.

We do not share sentiment but anyway its not what most users do, when thinking about ux you are aiming to be inclusive of everyone even that small percent.

oh, my apologies, didn’t realize that, shall i remove it? can do easily.