Description
Preconditions and environment
- Magento version: 2.4.8-p1
- A multilingual store with different URLs per category and product in the store views
Steps to reproduce
- Install a default LUMA installation with sample data
- Go to Stores -> All Stores and create a new store view let's call it
gr
(In this case the configuration for having category paths for product urls is automatically changed to "NO", we'll revert it back under STores -> Configuration -> Catalog -> Catalog -> Search Engine Optimization ) - Go to the Catalog - Categories
- Go to category Gear -> Bags
- Change the URL key from bags to tsantes for the gr store view
- Go to the first product Joust Duffle Bag and change the url key to joust-duffle-tsanta for the gr store view
- Uncheck the create permanent redirect
- Clear caches and go to the frontend.
- Notice that URL switching doesn't really work between store views.
- In my case I had to force the change to ?___store=gr by appending the variable
- Try to visit the greek store view URL of the joust duffle bag. You may notice a 404 or the page loading. Varies on how the steps are done.
- Try to go to the default store view -> The bag will show up
- Try to go to the gr store view -> The system redirects you to homepage
The error is due to how the switch is handled on the store switcher
The logic appears to be like that
In
The old rewrite is detected (if it can) to derive the context
Based on the request path which would contain both product id and category id for the store it will try to find an old rewrite. Sometimes this is not possible and the switch never occurs. If it finds the old rewrite it will go to next step
To identify the rewrite for the target store.
In this situation there are two cases,
- Because of the selection of the configuration options there is no rewrite generated for the request path including category id and product id the rewrite is not found.
- The second step as fallback is to find a URL based on the original request url for the target store. Because the URL has been changed it can never be found in the store based on the old rewrite. So this mechanism fails as well.
Then the target URL ends up becoming the homepage due to this line
As you can see there's a clear gap in the logic to detect the URL path when there aren't actual rewrites in the table, and the category path is included in product URLs as not all cases are taken into account
We may stumble into a lot of situations but definitely the system needs to be able to allow store switching and retracing the URLs back to the products.
Expected result
Store switcher always works no matter the underlying urls structure or paths including category path.
Actual result
Store switcher breaks easily
Additional information
You can view the video here https://plik.yourstaging.eu/file/lNGNRXBOUbQVFNrx/NCgNQGkUnzvlJGhh/xBgo0PRW3H.mp4 it will be up for 7 days
It's too large to upload on github
Release note
No response
Triage and priority
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.
Metadata
Metadata
Assignees
Type
Projects
Status