Technical TODO
Follow-up of shopware/shopware#17301 (related to #1795).
That PR introduces a new optional sw-domain header for the Store API. When a headless client sends the full URL of a domain configured on the sales channel:
GET /store-api/product
sw-access-key: SWSC...
sw-domain: https://shop.example.com/de
the backend resolves the language and currency from that domain on its own - no UUIDs needed. Precedence is preserved: an explicit sw-language-id / sw-currency-id header or a value switched in the context still wins, and an unknown domain returns HTTP 400 instead of silently serving the wrong locale.
Why we need it
It allows us to reduce the number of Store API calls during SSR. Currently in templates/vue-demo-store/app/app.vue the language-syncing flow on a server-side render is:
GET /context - initial session context
GET /language (getAvailableLanguages)
- If the locale resolved from the URL prefix differs from the session language:
PATCH /context (changeLanguage)
GET /context again (refreshSessionContext)
With sw-domain set as a default header (resolved from the current request host + URL prefix), the very first /context response already comes back with the correct language and currency, so steps 3a/3b (and the language-id lookup juggling around them) become unnecessary - up to 2 fewer API calls per SSR render, plus simpler logic in app.vue.
What to do
Blocked by
Technical TODO
Follow-up of shopware/shopware#17301 (related to #1795).
That PR introduces a new optional
sw-domainheader for the Store API. When a headless client sends the full URL of a domain configured on the sales channel:the backend resolves the language and currency from that domain on its own - no UUIDs needed. Precedence is preserved: an explicit
sw-language-id/sw-currency-idheader or a value switched in the context still wins, and an unknown domain returns HTTP 400 instead of silently serving the wrong locale.Why we need it
It allows us to reduce the number of Store API calls during SSR. Currently in
templates/vue-demo-store/app/app.vuethe language-syncing flow on a server-side render is:GET /context- initial session contextGET /language(getAvailableLanguages)PATCH /context(changeLanguage)GET /contextagain (refreshSessionContext)With
sw-domainset as a default header (resolved from the current request host + URL prefix), the very first/contextresponse already comes back with the correct language and currency, so steps 3a/3b (and the language-id lookup juggling around them) become unnecessary - up to 2 fewer API calls per SSR render, plus simpler logic inapp.vue.What to do
sw-domainheader in the API client / Nuxt module (resolved per-request from the incoming host and locale prefix during SSR)app.vue(demo store / starter template) to rely on the domain-resolved context instead ofchangeLanguage+refreshSessionContextFRAMEWORK__ROUTING_SALES_CHANNEL_DOMAIN_NOT_FOUND(HTTP 400) error caseBlocked by