appendStoreCode not working if VSF storeCode differs from API storeCode

[rain2o]

Current behavior

The scenario we want to accomplish is where Vue Storefront store codes in the URL are different from the store code in the API layer (and Magento for our case). We are still using the /:storeCode pattern, it just needs to be different. For example, https://mystore.com/en-us should actually send storeCode=en_us to the API. I have been unable to accomplish this without modifying multistore.ts to create our own custom workaround (more on that later). Currently, whatever if is the VSF URL as the store code is what is sent to the API.

I noticed this is because the value of storeCode within a store's JSON configuration gets set again in the code. So if I have something like

"en-us": {
    "storeCode": "en_us",
    ...
}

Later on currentStore.storeCode gets set to whatever was in the URL, making the en_us value completely useless.

So, I tried appendStoreCode: false and url: "mystore.com/en-us" and in mapStoreUrlsFor and the key of the store itself I used en_us. This caused a multitude of other issues, including a bunch of [vue-router] Duplicate named routes definition: errors.

The final functionality desired is fairly simple, but I'm afraid the logic that is necessary for all of the different scenarios of a multistore have caused this to be very complex. Our current crude workaround is just one line of code. Inside multistore.ts function adjustMultistoreApiUrl, we use the line url += urlSep + 'storeCode=' + storeView.storeCode.replace('-', '_').

If the appendStoreCode functionality could encompass this desired behavior I think it would make sense, but a simple alternative solution could be to add a new prop inside the store configs; something like apiStoreCode. You could make it optional even, and inside multistore.ts::adjustMultistoreApiUrl check if the prop is set or not, and either use it or fall back to the current behavior.

Expected behavior

Browsing to mystore.com/en-us would call the VSF API with storeCode=en_us. And having instructions around how the store code configurations work so that it's easier to setup the right configuration for certain scenarios would make things easier.

Can you handle fixing this bug by yourself?

• [x] YES
• [ ] NO

If it is decided to go with the alternative solution I recommended I can get something up and going. However, if you would like to encompass this in the appendStoreCode logic I don't know that I'll be enough help to figure it all out.

Which Release Cycle state this refers to? Info for developer.

Pick one option.

• [x] This is a bug report for test version on https://test.storefrontcloud.io - In this case Developer should create branch from develop branch and create Pull Request 2. Feature / Improvement back to develop.
• [ ] This is a bug report for current Release Candidate version on https://next.storefrontcloud.io - In this case Developer should create branch from release branch and create Pull Request 3. Stabilisation fix back to release.
• [ ] This is a bug report for current Stable version on https://demo.storefrontcloud.io and should be placed in next stable version hotfix - In this case Developer should create branch from hotfix or master branch and create Pull Request 4. Hotfix back to hotfix.

Environment details

• Node: 10.16
• Code Version: v1.10.3

Additional information

The following has been copied from conversations in Slack for full transparency and history of this issue.

---

rain2o I am in the process of upgrading our VSF to the latest version 1.10.2, and trying to use the new appendStoreCode feature so that we can have a different URL key than the store code in back-end (Magento). I'm having trouble getting it setup the right way though.

For example, our US store should be mydomain.com/en-us, but the store code used in Magento (and therefore in vsf-api) is en_us. I've tried just about every variation of the store codes, url, and appendStoreCode in the config file I can think of, but I must be missing something. I can't get them to work. I keep either getting too many redirects or invalid store code errors. Any suggestions?

lukeromanowicz I believe that you should set url to mydomain.com/en-us and appendStoreCode to false

lukeromanowicz Store code should be set to en_us though, same goes to storeview key, and an entry in url mapping.

rain2o Ah ok that might be where I went wrong. I was trying it so the url was just “/en-us”. But you’re saying it should be the full url not just the relative? I had everything else set the same.

rain2o I have been trying to get the setup you suggested working and I'm running into multiple issues. I'm still not quite sure if it's my setup, config, or this feature just isn't meant to work this way. I replaced my copy of vsf with vanilla vsf v1.10.2 to make sure none of my custom modules or theme are messing with it, and still the same issues.

The main issue I'm running into seems to be with appendStoreCode: false, the localizedRoute function doesn't actually do anything to the route (if it's not a category/product route), so it just returns it instead of localizing. I get the logic behind this, but the problem it introduces is I get a ton of [vue-router] Duplicate named routes definition: errors, for every route I have defined in the theme and every store I have active. Since it isn't localizing those routes it's creating duplicates for each of them per store.

Beyond that I'm still getting issues with things like /core/modules/url/store/actions.ts::mapUrl() not seeing the correct store because storeCodeFromRoute is trying to use the /en-us to get the store, so then it falls back to mappingFallback. Same with /core/modules/url/router/beforeEach.ts, the to route doesn't have host in it for some reason, so when it calls storeCodeFromRoute(to) it doesn't make it to the line where it adds the host to the url variable.

It seems like a series of issues, I'm just trying to figure out if I'm doing something wrong, or if it just isn't built to work the way I'm trying to use it.

rain2o The store config has always seemed a bit confusing to me. When I see

"mapStoreUrlsFor": ["de", "it"],
"de": {
    "storeCode": "de",
    "disabled": true,
    "storeId": 3,
    "name": "German Store",
    "url": "/de",
    ...
}

I would expect the values in mapStoreUrlsFor to match the key of each store, and then the value of storeCode within each store to be the value that is sent to backend api, and would expect those to be able to be different values. But it has never worked that way from what I've seen. If it could work in a way like that, then this would be a lot more simple. Of course that only applies to the scenario where you want a storecode appended to the url, but you just want it different than the backend storecode. In other scenarios like different domains or sub-domains the feature you've built here is great for that.