Hi,
I’m looking to use more direct URL’s for individual users.
Currently I’m using https://beelink.co/hub/jj. Any way to remove the /hub/ (i.e beelink.co/jj)?
I’ve seen this question posted before but haven’t found any conclusive answers.
Thanks, JJ
The answer to this question – that you cannot have yoururl.com/arbitrary_alias without messing up essential 404 behavior – is most decidedly conclusive (as of this writing, 02/25/2019). While you can do it, the pages that you seem to direct to are throwing 404 errors back to the agent viewing the pages. So such pages will never be indexed properly.
However, you can have AWESOME /u/arbitrary_alias pages that DO NOT break Bubble’s built-in “send data” functionality, while still enabling a friendly social sharing URL, etc., with support for multibyte characters, etc. and pages that WILL get indexed in search engines (if you desire).
And, I built it for you: All you have to do is understand and copy what I did in the following example project.
SO, here is the sexiest and most correct way to do yoururl.com/your_choice_of_profile_page_names/arbitrary_alias, (again, as of this writing, 02/25/2019), examine the project called gibu (“gib username!”):
Run mode:
Live: https://gibu.bubbleapps.io
Dev: https://gibu.bubbleapps.io/version-test?debug_mode=true
Edit mode (anyone can view):
I’d recommend you visit live mode first, sign up and have the whole experience, then examine what’s happening in the editor and dev preview modes (extra debug type info is revealed in dev mode).
For a great deal of explication about how this is built, see my explanations in this thread:
(I realize that I did not respond to the very very last of comments in that thread… I’m sure someone following this example could come up with the answer to beau’s questions about back button behavior and I suspect beau probably figured out how to enable that to work in the way that they like.
While I will revisit this example on occasion if new features require changing how this should be done, you should realize that, personally, I don’t think any of this is particularly interesting or worth it. So I built this as an exercise and to serve as the “last word” on how this should be done. I’m not taking more questions on it, ATM.
But I realize that some people want to mimic such behavior in their apps, so I did my best to build the best emulation of this possible in Bubble. (That preserves all editor/dev mode/debug mode functionality, does not interfere with arbitrary URL parameters, etc., etc. There are a great many well-thought-out features here.)
The reason I say this is an emulation, is that the REAL way you would do this is with server URL rewrite rules. We do not have access to those in our Bubble web stack and so cannot do this in the exact fashion that, say, LinkedIn would do it. And if Bubble DID let us do that, many of those who want to incorporate such functionality would be all up here whining about how it’s too hard to write said server URL rewrite rules “because they are not coders.”
So, this example is about as easy as it gets. And it enables some fairly out there features that you just don’t see in most social networks. I mean c’mon, users on gib/u can have EMOJI USERNAMES! It’s pretty rad. Examining the project will teach you a bunch of cool tricks that you may not know yet. (There are “bonus beats” all over the place in there.)
Hope this helps,
Keith
5 Likes
Hey Keith,
Thanks for your reply! I understand your point - I’ll stick to using /hub/.
Cheers,
JJ
1 Like
I read through your gib/u tutorial @keith and was wondering whether the same can be done for none user data? As in, is there a solution to send direct links for non-user data (i.e. property) within a single page just like gib/u?
Hey @jamesbond, of course you can. Just give whatever thing a URL-friendly text-type identifier field.
But you don’t even have to do that. For the non-User case, all you are talking about is using a URL parameter to look up some object of some type.
(That is, this is just one of many common uses for URL parameters.)
The difference here is that it’s rather simpler as we don’t have to accommodate “Current User” right? There’s no analogous property for other data types. (A Property or Listing or Headquarters Address or Turn On will not be viewing your page. So of course we don’t need to detect and do something special there, as we do in gibu for Current User.)
To provide a bit of a conceptual overview of this approach (which @keith has documented and described so well)…
Basically, any Bubble page (except for the home page) can function somewhat like a “router”. The “path” (which appears after the page name in the URL) can be used however you want in a workflow. Typically, it’s an id/slug/string that’s used in a DB look-up.
So for instance, you could have…
mysite.com/cuisines/thai
mysite.com/rentals/7266401
mysite.com/users/username
…where cuisines, rentals, and users are the actual Bubble pages. Then, on each page, you’d grab the path (thai, 7266401, or username) and do what you want with it (e.g. display a list or retrieve detail). In the gib/u example, “u” is the name of the actual Bubble page.
1 Like
My problem is that when I reload the page, the data that was displayed isn’t viewable anymore. For example, lets say I have a single app with hidden groups. A button is then clicked from a repeating group to display data in a hidden group and also send URL parameters to navigate and show that hidden group. If I was to reload the page, the hidden group will still show (as normal), however, the data displayed would have disappeared on refresh, although I suspect this is only happening because I’m simply displaying data from another bubble app that is not stored in this app’s database. Do you think that’s the reason why the data is disappearing?
OK, so you’re building a single-page app, basically?
Note that you do not need to reload the page to engage in new modes of behavior.
Building a URL with URL parameters is (one) way of re-creating the state that such an app was in if (for example) the user leaves and you want to pick up where they left off. (The URL parameters are used to convey state information.)
But of course you don’t have to do that. You could also retrieve the last state from some status indicator that you store in the database. Or you could use cookies.
The thing with single-page apps and Bubble, is that you always have the database. Don’t try to build a substitute database using URL parameters and don’t build a crazy state machine using URL parameters.
URL parameters are for transferring some temporary state to a new page (preserving some context between page loads that – for whatever reason – you do not want to store in the database).
1 Like