I have a table. When you click on a table row, it opens the details of that row in a modal. Up until now I’ve set a selected_row variable onClick and passed that variable to the modal to pass the data.
Fast forward to today, I am trying to deep link to a modal. My first attempt has been to append id=123 to the URL, then on Page Load, check if the URL query exist, and if so fetch the object for that ID, to pass to the modal, and open the modal. I’ve got all that working fine, but what I can’t seem to figure out is how to clear that URL query when closing the modal.
What I’ve tried:
- Custom javascript which deletes the query – this works in isolation (pressing the test button on the action) but doesnt nothing when triggering the workflow in Preview. This feels like the best path forward, if only I could get it to execute in practice.
- Navigate to a page – this shouldnt really be necessary since the page is in the background of the modal ; still I tried to “delete the query” by both no setting one as well as setting it as an empty array.
- I finally truend to WeWeb AI, which suggested something similar to 2, but instead of navigating to a Page, navigating to a Path; otherwise all the same. Nothing.
- I asked Claude, after providing all this context and it recommended to custom javascript that forces the page to refresh, which accomplishes what I want, but at the expense of UX
.5. I guess I could set the query to empty, keeping the query key there, but that doesn’t feel all that elegant.
1 Like
Have you tried using reset action or changing the query via change variable value to null or something similar?
Thanks for the quick response. Not sure I follow—Im not using variables here so how would I find the “variable” in either the Change Variable Value or Reset Variable Value actions to modify the query? I found a solution, but curious if your path reveals a better way to do this.
The following code is what I was referring to in #1. Since this worked when pressing the test button in the Custom Javascript ation (research suggested the routing behaves differently in Editor) I took a chance and deployed it. To my surprise, it actually worked as expected.
const url = new URL(window.location.href);
url.searchParams.delete("id");
window.history.replaceState({}, "", url.toString());
Now that I have this working, I’ve moved onto the next phase of the feature—if a user is not authenticated then we need to store the url (path and queries) > direct to sign in > and then redirect to the respective path + queries.
When a user lands on a page and is unauthenticated…I store the path and the queries of the original URL in a variable > redirect to the 2FA sign in flow > and upon verifying the code trigger the following action.
Tip: for any future readers, despite the queries natively being stored as an object, the queries input expects an array in the following format [{"name":"key", "value":"value"},{"name":"key", "value":"value"}]. This took me a while to get to this point.
So I’ve gotten to the point where my dynamically bound Queries are working, and I can hardcode the path, eg “offers” —the logic in the screenshot below successfully redirects to the proper page with the queries appended—but as soon as I bind the Path to the “path” value in my variable it wigs out. Obviously the path in the Editor is some random alphanumeric sequence, so I took a chance and deployed it to Production to rest, wondering if this too was victim to the Editor routing, but no luck so I had to rollback.
Hi @archenia_jsanchez nice workaround. Could you please elaborate why you had to use JavaScript for this? How are the no-code query variables not satisfactory? Intro to variables | WeWeb Documentation
You can change the query using the Change a variable value action or reset it.
I’ll have to look into the query** variable—I’ve never dug into it in the past, probably because I’ve never had a legit use case. Also, after watching the video I wonder if all the selected_* variables that I’ve created should be reconsidered through this lens. I’ll have to give it a try now that I know what that variable type is.
** I’ve seen this variable in the drop down list but it just wasn’t intuitive to me—“query string” or “query parameter” is the label I think of—and as such never had the feeling that this was something I needed to use or research. 
Aww, heck. Reporting back to share that the query variable seems to be doing the trick! I now understand what you were hinting at, @Broberto — resetting the query variable on modal close automatically removes the query string from the URL. I wish I would have discovered/learned this much earlier and could’ve avoided a lot of headache.
Now to chip away at the unauthenticated experience…
1 Like
@DanielL might you have some advice on how to handle the unauthenticated experience?
For example, a user clicks on www [dot] archenia [dot] com/offers?tab=available&offer_id=123 only to find out they are unauthenticated. The way I am handling this is:
- on page load of the Budgets page, before fetching collections, I check to see if the user is authenticated. If not, I store the url path in a text variable and the tab and offer_id in individual query variables all in local storage
- The app redirects to the sign in page, based on my experience testing in Production with “?_source=/Budgets” injected into the URL
- I go through the OTP flow and upon clicking “verify code” I run a workflow that checks to see if that redirect path is not null. If it is null, then navigate to the home page, otherwise navigate to the redirect page. I’m attempting to do this by mapping the Path to my path variable and hardcoding the query parameters (see screenshot below) but am not having any success; in case you are wondering, I am hardcoding the query parameters because it’s unclear how to store all queries in the originating URL, and then loop through them all and add them to the query parameters.
** where I am having trouble is, ideally the app can manage redirecting any inbound URL so the page/path and the queries need to be smart. I’ve only been successful when I’ve hardcoded Page = Budgets. I was hopeful that the path would work in Production because the routing is more straightforward but that doesn’t appear to be the case.
@flo @Matthew_S thanks for the time in Office Hours. I took the advice and have the following:
- On page load, if unauthenticated, set
redirect_path to window.location.pathname.substring(1) + window.location.search; to
- redirect to authentication
- if
textLenght(redirect_path)>0 then “navigate to w/ path” ..
it looks like the Editor is replacing part of the URL with (or adding to the beginning) “ww_front”. I want to blindly trust that this will work as expected in Production, but right now in Editor its not behaving as desired. Is there anything I can do to solve for this?
Immediately following up to my own thread, I stepped through the code and the above was causing an error.
I manually updated the variable from the Log by
- first, replacing
ww_front with what I think is my Editor UID or something 8f650259-b761-40cb-954f-dd4754073715 (which didn’t work); and then
- then, replacing the entire path Editor path
/8f650259-b761-40cb-954f-dd4754073715/010403a8-eea7-4468-b059-002734aabcc0 with Current page.paths.default which is budgets (this is what solved it)
So, I’ve gone back to where I am setting redirect_path variable and concatenating Current page.path.default + window.location.search
This FINALLY works as desired, and think I’m going to check this off as done. Still, what I thought was the obvious solution didn’t work, and what I have feels like its bandaged together until it worked—which I just am waiting for something to break. Can y’all provide some feedback on my solution?
CORRECTION.
The solution does not work in Production. It appears that Production and Editor do not behave the same when it comes to configuring Private Access for pages.
I have all restricted pages set to “authenticated users” only. It appears that in Production, the page never loads and so any App Load or Page Load workflows that I’ve built (at least at the page level) are completely ignored. I’ve validated this by changing this setting > deploying > and watching the local storage variables in the Inspector console. I can see that the local storage variable is being set ONLY when the page is set to “Everybody.” I’ve also moved the workflow from the page level to the app level.
Unfortunately in doing so—changing the access level regardless of where I place the workflow—the Budget page loads for a brief second and then redirects to Sign In which doesn’t look elegant. Surely there has to be a better way to do this.
This is quite the thread. A bit beyond my understanding but I’m hoping to accomplish a similar outcome.
Clicking on a Row, opens a Modal of an item ID. It seems you had to accomplish passing that ID in the URL via Javascript as a URL parameter?
Hopefully this should help:
pt 1: https://screen.studio/share/OhwhVuhv
pt 2: https://screen.studio/share/SYXGaihn
I recorded the first part, then saw the issues you were having with the restricted access pages 
@matt-thrive
Previously, I had a variable, of type object, called selected_offer. When a user clicked a row, I set this variable to data.item (the data bound to the row via the repeating items from the collection). This way all of the row’s data could be referenced in the modal.
Now, what I am doing is, I have a new variable called offer_id, of type query. When a user clicks on a row i am setting offer_id to data.item.id which automatically appends “offer_id=[row id]” to the URL. This allows me to do the external deep linking—I’m not sure it’s necessary otherwise. For now, I am still creating the selected_offer object too as I was doing previously to pass all that data which is already present in the table to the modal, but I suppose you could simply take the id and fetch the data on modal open for various reasons.
Thanks for the videos. Unfortunately I’ve been poking at my configuration, and unless I do some overhaul I’m concluding this just isn’t possible.
- your solution uses a product detail page, which with it has its own url parameter, eg
product/12, whereas I have a list page with an offer detail modal, eg budgets?offer_id=123
- the Supabase unauthentication redirect only passes the path, no query strings, so in your solution
_source is properly set to the product/12 whereas in mine, its still only setting to budgets. I suppose I could change the modal to a page, but I’m not too keen on that at this moment.
- Since the redirect is happening automatically with the Supabase Auth plugin, I dont see a way to correct
_source before it redirects to Sign In. Unless I’m mistaken, no workflows will trigger before redirecting from budgets?offer_id=123 to sign-in
- If I were able to get the query strings, I think I understand how I can either a) store that variable in local storage to redirect after Verify OTP Code, or b) I imagine I could Navigate to Verify OTP Code page w/ the
_source still attached to the URL
Ok, I think I fully understand now.
Here is a more manual approach I think you can work with: https://screen.studio/share/IITvcZtw
Thanks, Matthew! This all makes sense. I had explored something similarly before—public page with a workflow that controls the unauthenticated redirect—but I failed to include the conditional rendering and so I moved on from that solution shortly after seeing my Budgets page load for a moment before redirecting and not thinking to troubleshoot that part. Thanks for all the support 
** P.S. I didn’t know Screen Studio now does sharing hosted videos! Looks like I’ll have to upgrade my license to unlock that feature.
1 Like
