After building some huge server actions based on passing server side information through PHP session variables, I have found out that these values are shared between versions of my app running in different browser tabs.
Upon looking for a solution it seems that session variables can be stored as an array in PHP, with one field being some kind of unique identifier to the browser tab that is open.
This a request for the option for Wappler PHP Session variables to be implemented using arrays in the background so that we can keep the same simple user interface and have session variable values which are browser tab independent.
Generally, I would have thought people wouldn’t expect session variables to be tab-specific. I don’t mean in a technical way, but in a way a user might assume things work. Eg if someone logs into their Amazon account, I suspect they might be surprised if they opened other tabs (viewing the same website) and found they were logged out when viewing these tabs - but still logged in on the initial tab. Or, even more problematic, that they could have multiple tabs, each with a different number of items in their shopping cart.
I’ve never come across a situation where I would want session variables to be tab-specific and I would have thought a different approach might offer a better solution (eg the solution suggested by @Dave in the related thread).
Also, to keep track of what’s happening in relation to PHP session storage (and to observe its persistence), you can open up a session file and see exactly what’s stored in it, at least if you’re developing locally. It’s just a text file named according to the session cookie name, which you can see alongside the other storage options in the browser developer tools.
Could you add a condition (to your actions) if session x then do y, if y then set and do x, etc? Or just face the music and acknowledge that version 0.2 of your app doesn’t rely so heavily on sessions… Painful realisation that I think most of us have encountered in our respective journeys, just as you think you nailed it the bottom falls off. Been there a fair few times. It’s possibly why we focus more on desktop and mobile now then web apps. Allows us that little more control. And I’ll be honest am kind of a control freak hahaha… Sorry to make light of it Antony, I do not mean to. Just sometimes its best to bite that horrible tasting bullet…
EDIT: Maybe you could just add a new Server Action above everything in your page which makes the above checks and balances for you, then fires everything else, ie set all those Server Actions to ‘No Auto Load’, and on the new Server Action fire an on Success Action to load the other Server Actions on your page? Then if the sessions are messy you can rectify them before the rest of your Actions serve data… A Preloader will hide all this going on behind the scenes, you can also trigger this based upon success etc (you probably already know this).
Yes, I guess this is an interesting use case… where you may end up with two tabs open accessing different booking forms for different events.
I’m just going to bite the bullet, sit down one day this week with a copious flow of tea and some relaxing music and switch it all over as I described.
My son Toby is running a complete testing operation for me now with very really spec’d test procedures so it will be very easy to know I’ve got it right!
Or, simply, disable right clicking for now! Irritating as &%$* but will stop most opening a load of tabs! My business partner is a total git (polite English for utter bastard) when it comes to breaking things trying to short-cut left, right, and center…
That scenario does not turn me on. Maybe give each form a random generated key in an input variable (easy to do in PHP), a use once key of sorts. Insert this in to a table somewhere and check its only used once and doesn't exist? If it exists generate another random and insert that....
