In these pictures, you can use I have a user Joe@schmoe.com. I even try to log him in. The api call worked once (block count is now a different number, so I know its not working)
What am I doing wrong? Why isnt the user getting updated? If it were getting updated, a value would appear in CurrentBlock
UPDATE: I believe the problem is in the “when page loads” event. I do not think it is doing the actions I am asking it to do. So Now I am stuck with …why doesnt that workflow work? I have no idea
Another update: Debugger shows that “page is loaded” event works. Also the user login works. But that the API is not being called in the next step. Debugger just stops working right, so I am unsure of how to tell what is happening
Even the debugger doesnt like this bubble for some reason. Something is wrong with the API calls. It just makes bubble crap out. I have tried in safari and chrome. But the calls totally work when I initialize them or try to modify them.
Check out the awesome video of when I have no idea how to fix this.
Usually you only want to log in on a button press… typically on the home page. If they are not logged in then redirect them to the login page.
Once logged in allow them to access pages that require them to be logged in. You can enforce that they are logged in by using a “Page is loaded” step with an “Only When” of “Current user is logged in”. If they are not logged in then, redirect them to the login page.
Thing is, I dont want anyone to log in or sign in at all. But I could see how to make anything work without it. This is just informational. So I only want one user, current user.
You may need to explain what you’re trying to accomplish to get help. Without further details I don’t understand the reason to log someone in, even though no one should be able to login.
Hmm. It was not obvious to me how to do anything without having someone signed in. I give the user new fields to store data. then I can reference and update those fields because the dropdown for dynamic data always assume a Current user.
I’m with @Kfawcett on this. The whole idea is cockamamie.
If your app doesn’t have users, DON’T store stuff on a user. You can just have global values. That’s totally fine.
But If you need to differentiate AND REMEMBER stuff for different individuals, then your site needs a User data type.
That what the concept of “Users” is for!
Now, you CAN — with some work — have a site that runs on a concept of local sessions/local storage, or writes cookies or whatever, but that instantly takes you out of vanilla Bubble. Someone created a local storage plug-in and cookies are easy enough with some JavaScript (you can search @keith and “cookies” to even find a video I made about simple cookie usage in Bubble). You could also just have a ridiculous number of URL parameters if your app changes pages.
However, I really really think you’re confused about what it is you are trying to do.
If a non-Logged in user needs to provide information (like whatever the heck your “numoflottos” variable represents) just provide an INPUT for that value or just use a default value or whatnot.
(The value provided in the input can be shoved into a “custom state” more or less anywhere on the page. Custom states are what Bubble calls local variables. They only live as long as the page of course.)
If your app doesn’t have users, DON’T store stuff on a user. You can just have global values. That’s totally fine.
Well that’s what I wanted in the first place. But when I approached it that way, I could never find what I was looking for in the drop downs.
But If you need to differentiate AND REMEMBER stuff for different individuals, then your site needs a User data type.
That what the concept of “Users” is for!
Yes that is why I approached it that way first. And bubble never gave me the items I was looking for until I created a user and put the fields I needed in it. That is why I came to this forum with my original set of questions about why I needed to have a user and why bubble assume dI would hav one.
The link to what I wanted to do in the first place is above. I never wanted a user. I couldn’t make it work without having a user. Hence my question from the beginning. No need to make fun of me because I couldn’t figure out how to make bubble present me the items I was looking for in the first place.
You just create your own data types and create things of those types. It’s not particularly hard to change your approach without redoing everything.
In the case of custom states, you simply create them in the page. Custom states are nothing more than local variables – places you can put stuff. Unlike in JavaScript (where the data type of variables is dynamic), custom states always have a data type.
Custom states can be created interactively as-needed in any expression editor field, but it is perhaps easiest to create them from the element inspector. Here’s a real-life example of an element (a group) with rather a lot of custom states:
You open the inspector by clicking the “i” button at the top of the element dialog. This displays the pane shown on the right in the above image. There’s a handy link at the bottom (circled) which allows you to create a new custom state without having to be in the expression editor.
You’ll also note that this image demonstrates that local variables (custom states) can have not just primitive/native data types but can also have complex data types that we’ve defined in the Data tab (or that come to us via the API Connector). (“iCalFromURL Event” is an example.) You’ll also note that custom states can be either single values or arrays of values (lists).
So what you’ve looking at here is basically the local/in-page version of the Data > Data types tab.
The caveat with in-page data / custom states / local variables (whatever you want to call it) is that it does not persist when the page goes away (unless of course, you save it to the database or otherwise transfer it between pages via URL parameters.
It occurs to me that one could build a site/app with Bubble that, instead of treating the database as a persistent repository of (mostly) User-centered data, one could use the database as sort of a rolling cache of data that we regularly throw away.
The concept would be that more-or less all pages in your site have a data type – and only one data type. That data type would be called “Session” or something similar.
Pages with a type are typically expected to have the unique ID of the specific thing of that type as the last part of their path. For example, here’s a page on my own real-live app that has a type of “Listing”. When hit with the unique ID of a Listing, it shows a calendar of that Listing’s availability.
^^^ The hilighted part of the URL is the unique ID of the Listing to which this calendar belongs.
If we hit this page without the Listing part of the path, the page essentially “breaks” as there is no data to feed the calendar – it’s just sort of a “shell”:
Of course, Bubble gives us the capability to detect this situation and do something if we should want to. In a workflow, we can do something like this: Detect if the thing is empty (the URL has been hit without the unique ID of a thing of the page’s type) and take action.
Typically this would be used to either redirect the user to some other page, or display a message that there’s nothing to see here, but we could do anything we want. Here’s how that works:
One “anything” would be to use this idea to assume that, if a page is hit without a Session object ID, the visitor must be in a new. They are not currently in a Session and we could create a Session object should they choose to continue.
As they change pages, we pass the Session object we created just for this “session” to other pages. We use the Session object to store anything that we need. If we’re on a paid plan, when we create the Session object, we can at the same time schedule it to be deleted at some future time (take your pick - some minutes, hours, or days from now) and all that object will go bye bye.
This is what I mean by using the database as a rolling cache.
So, in much the same way that you that folks lazily (or for lack of other knowledge) shove everything onto a User object, we would actually shove everything onto the Session object (or associate other objects with the Session object and also delete them when we delete the Session object).
I like this idea so much (even if it’s not super-useful) that I’m going to create a little demo app illustrating the principle.
![10%20AM|533x63]
