Hey @nikita , i see from your posted verbose output that you are using a toml file, but aren’t providing the store-password. Have you tried passing it in as well?
I just tried again, providing a store-password, and it doesn’t fix the issue I’m seeing.
Additionally, using a development theme (no --environment), does not cause the storefront password loop on the same store, without any change to storefront passwords, and without a providedstore-password.
Can you screenshot the error/loop you see in your terminal? I am unable to recreate it on my end, but want to confirm we’re talking about the same issue here.
The loop I’m seeing is not in the terminal but in the browser, on the local preview.
I’m working on an unreleased update to a premium Theme Store theme so I’m afraid I can’t share a screen recording of the actual error I’m seeing on this forum. Happy to do so in private.
That said, I have isolated the behaviour to pages with the within filter and can replicate the same error with the Horizon theme.
o wow you weren’t kidding about that filter - i see it now too. Hmm I have a weird hypothesis, but I think there might be an issue with the URL itself, not necessarily the within filter.
My hypothesis:
The within filter should return the product url with the context of the collection, right?
What if the collection doesn’t exist?
“all” isn’t a real collection you configure on Admin
I have a collection called “frontpage” in my Admin so when i click on an item there, it navigates to the right product page within the context of that collection, no password requests
ie. http://127.0.0.1:9292/collections/frontpage
However, when the collection doesn’t exist, in development mode, instead of sending us to a 404, it just redirects us to the home page, and that triggers a password request
I was able to recreate this issue locally, but wanted to confirm if clicking on products within a real collection worked for you as well.
I have a weird hypothesis, but I think there might be an issue with the URL itself, not necessarily the within filter
This must be the case, however there’s also something else about this specific scenario that causes this to happen.
If I use a development theme (no --environment), both links from the all collection and ‘real’ collections work just fine, and products are displayed with the within url, e.g., even this:http://127.0.0.1:9292/collections/all/products/orange-snowboard works fine on a development theme.
If I use a development store that was created prior to the dev dashboard, both development themes and regular unpublished themes specified in the environment work fine for both all and ‘real’ collections.
Hmm yeah i was able to do that too on Horizon. I initially thought it was the Theme Access App, but then i noticed that when i navigate to the product (with the /collection/all/products/orange-snowboard url), followed by pressing “Back”, i get prompted for the password again.
When i looked at the URL i noticed it navigated to collections/all?page=1 - obviously the “all” collection doesn’t have pages, so that’s why it’s invalid.
There is definitely something funky going on where whenever we hit an invalid URL, you are pushed to a the password page. This isn’t a CLI issue, but does seem like a rendering/routing issue. I’ll see who i can poke around for this issue. Thanks for bringing it up @nikita !