Skip to content

Enabling category path in product urls breaks store switcher in multiple ways #40037

Open
@ioweb-gr

Description

@ioweb-gr

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

  1. Install a default LUMA installation with sample data
  2. 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 )
  3. Go to the Catalog - Categories
  4. Go to category Gear -> Bags
  5. Change the URL key from bags to tsantes for the gr store view
  6. Go to the first product Joust Duffle Bag and change the url key to joust-duffle-tsanta for the gr store view
  7. Uncheck the create permanent redirect
  8. Clear caches and go to the frontend.
  9. Notice that URL switching doesn't really work between store views.
  10. In my case I had to force the change to ?___store=gr by appending the variable
  11. 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.
  12. Try to go to the default store view -> The bag will show up
  13. 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

$oldRewrite = $this->urlFinder->findOneByData(

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

$currentRewrite = $this->urlFinder->findOneByData(

To identify the rewrite for the target store.

In this situation there are two cases,

  1. 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.
  2. 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

$targetUrl = $targetStore->getBaseUrl();

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

No type

Projects

Status

Ready for Confirmation

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions