Repository navigation
Keep the storefront exit page working in the theme dev server - #9012
Conversation
|
@bashu-shopify good catch on Theme Access (also TIL that exists). Let's try to get this fix in, and then open another PR for fixing Theme Access. I'll try to get this landed for a 5.0 patch; just need someone with magical permissions to review. |
bashu-shopify
left a comment
bashu-shopify
left a comment
There was a problem hiding this comment.
hi josh.
I think this rule becomes broader than the exit page behaviour. It runs on every proxied response, so POST /localization gets it too. A market redirect like https://mystore.fr/products/new used to become a local path. Now it goes to the live site.
The storefront does send these. _fd=0 only stops the primary-domain redirect. The overridden market redirect still fires, and market_web_presence_redirect_integration_test.rb asserts it. Core's localization 307 looks like it ignores _fd too, though I haven't run either.
so, request: Could we limit the rule to the exit page? That page only redirects to the destination, and it returns a 404 for destinations on the store's own site. So the store-host branch never applies to it. The rest of the proxy could keep the old behavior, and the // fix would still apply there.
Would that work for you?
Only the storefront exit page keeps redirects to other sites absolute. Every other proxied response, such as POST /localization, keeps the previous behavior: a non-checkout Location becomes a local path, so market domain redirects still stay on the local server.
|
@bashu-shopify good catch! Updated. |
WHY are these changes introduced?
In
shopify theme devand theme app extension previews inshopify app dev, clicking a link to another site always showed the storefront's "leaving this store" confirmation page. That happened even when the live store or the admin theme preview sends the shopper straight there.The dev server's proxy caused it in two ways:
/url) only continues to another site when the request is a real navigation (Sec-Fetch-Mode: navigate). The browser sends that header to the local server. The CLI then re-sends the request with Node's globalfetch, which always replacesSec-Fetch-Modewith its own request mode (cors). So the storefront showed the confirmation page every time.Locationheader.https://example.com/became/, and the shopper landed back on the local server.WHAT is this pull request doing?
storefront-renderer.ts: a GET to the exit page (/urlor/:locale/url) is sent with cli-kit'sfetch(node-fetch), which forwards the browser'sSec-Fetch-*headers unchanged.redirect: 'manual'and the same error handling.slow-requestmode, so there are no retries and no timeout, the same as the globalfetch.Response, and everySet-Cookieis kept.proxy.ts: aLocationheader is only turned into a local path when it points to the store (a relative path or the store's domain). Redirects to other hosts stay absolute. For store redirects, the existing_fd/pbcleanup and the checkout exception are unchanged.How to manually test your changes?
shopify theme dev, orshopify app devwith a theme app extension, using this branch.https://example.com/)./cartor localization redirects) and checkout should work as before.Checklist
patchfor bug fixes ·minorfor new features ·majorfor breaking changes) and added a changeset withpnpm changeset add