url_rewrite deleted or contain wrong url_key when saving product on storeview

[mveldhuizen]

Preconditions and environment

Magento version: => 2.4.7 Multiple storeviews in 1 website (example default and german) Configuration:

• catalog/seo/product_use_categories = yes
• catalog/seo/generate_category_product_rewrites = yes

Steps to reproduce

Example 1:

1. Create a new product (test-product)
2. Edit product in scope of storeview (example german)
3. Add product to a category in this scope
4. save the product

Example 2:

1. Create a new product (test-product) and add product to a category (in global scope)
2. Edit product in scope of storeview (example german)
3. Change url-key of the product in this scope
4. save the product

Expected result

Example 1:

Product should have rewrite urls for both store views:

Example 2:

Product should have valid url rewrites for both stores and use the correct url_key for each store:

Actual result

Example 1:

Product does not have a url_rewrite for the other storeview:

Example 2: The url_rewrite without any category link is removed. And the product url within the category of the default storeview now contains the url_key from the german store.

Additional information

I think the new system in magento 2.4.7 for saving url rewrites for multiple stores is the issue. This was introduced in: https://github.com/magento/magento2/pull/35053

app/code/Magento/CatalogUrlRewrite/Model/ProductScopeRewriteGenerator.php:219 checks if store is global (which it is not) and then runs generateCategoryUrlsInStoreGroup which has some flaws which result in deleted or broken url_rewrites

There is a workaround when the product has wrong url_rewrites. You can edit the product in admin store and update the categories (add one, save, remove it again). This regenerates the url_rewrites and as it is saved in admin store the url's will be correct. This bug only happens when saving in a specific storeview.

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.
• [X] 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”.

[m2-assistant[bot]]

Hi @mveldhuizen. Thank you for your report. To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, Add a comment to the issue:

• @magento give me 2.4-develop instance - upcoming 2.4.x release
• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[m2-assistant[bot]]

Hi @engcom-Bravo. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• [ ] 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• [ ] 5. Add label Issue: Confirmed once verification is complete.
• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[roman-michak-hh-global]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @roman-michak-hh-global. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @roman-michak-hh-global, here is your Magento Instance: https://9726342261dda0c8388f43250298023a.instances-prod.magento-community.engineering Admin access: https://9726342261dda0c8388f43250298023a.instances-prod.magento-community.engineering/admin_3c92 Login: eb915a8d Password: 8f199513b96d

[engcom-Bravo]

Hi @mveldhuizen,

Thanks for your reporting and collaboration.

We have verified the issue in Latest 2.4-develop instance and the issue is reproducible.Kindly refer the screenshots.

Example 1: It seems to be working fine. Product should have rewrite urls for both store views

Example 2: product url within the category of the default storeview now contains the url_key from the german store.

Hence Confirming the issue.

Thanks.

[github-jira-sync-bot]

:white_check_mark: Jira issue https://jira.corp.adobe.com/browse/AC-12843 is successfully created for this GitHub issue.

[m2-assistant[bot]]

:white_check_mark: Confirmed by @engcom-Bravo. Thank you for verifying the issue.
Issue Available: @engcom-Bravo, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[mveldhuizen]

Hi @engcom-Bravo,

Thanks for confirmation of example 2.

For example 1 you say: "Example 1: It seems to be working fine. Product should have rewrite urls for both store views". The problem with example 1 is not that the category urls are wrong but there is a missing url rewrite for store 1 to the direct product url. So your screenshot does not prove that example 1 is not an issue.

So in your dataset I would expect another 2 rewrites for "test-product.html" (without category) that link to "catalog/product/view/35", but the one for store id 1 is missing.

Thanks.

[MaximGns]

Hi, I can confirm that we also have this issue after upgrading to magento 2.4.7

We have 2 storeviews in the same group.

We save the dutch version of the product on the default store (0), this generates it correctly. Then our importer saved the french product ofcourse on the french storeview and this breaks everything.

If you see in the screenshot, the dutch storeview has french category names. Now the funny thing, if I now save the product on the NL storeview the situation of screenshot above is "reversed"

Now french urls are containing dutch category names.

Something is crearly really wrong with recent magento version :)

[vandijkstef]

+1, same issue on 2.4.7.

When you save a product, using a specific store-view and having changed the SEO url key, Magento takes that SEO url key and applies it to all store views within that store group. So, having the views GroupA_ViewA, GroupA_ViewB, GroupB_ViewC:

• After saving url-key 'test-a' on GroupA_ViewA -> url-rewrites for GroupA_ViewA and GroupA_ViewB are set to 'test-a'
• After saving url-key 'test-b' on GroupA_ViewB -> url-rewrites for GroupA_ViewA and GroupA_ViewB are set to 'test-b'

Expected:

• After saving url-key 'test-a' on GroupA_ViewA -> url-rewrites for GroupA_ViewA are set to 'test-a'
• After saving url-key 'test-b' on GroupA_ViewB -> url-rewrites for GroupA_ViewB are set to 'test-b' - GroupA_ViewA to be unaffected

The issue is only there when the product is set to a category - with an empty category everything is working fine. Changes to SEO url where made without adding redirects from the old url

[vandijkstef]

I think the new system in magento 2.4.7 for saving url rewrites for multiple stores is the issue. This was introduced in: https://github.com/magento/magento2/pull/35053

Following the above suggestion and diving into Magento\CatalogUrlRewrite\Model\ProductScopeRewriteGenerator I find the following code:

if ($isGlobalScope) {
    $generatedUrls = $this->generateCategoryUrls((int) $storeId, $product, $productCategories);
} else {
    $generatedUrls = $this->generateCategoryUrlsInStoreGroup((int) $storeId, $product, $productCategories);
}

Which is essentially saying; You are either globally setting these rewrites OR we just apply this to the entire store group. As the url_key attribute is a store view scoped attribute this basically cannot exist, as essentially this is causing url_key to act like a store group scoped attribute.

The issue will only apply when a change is detected to the url_key, but when doing so, it breaks urls for other store views within the same group therefore I kindly request this issue to have a raised priority.

As a workaround disabling the InStoreGroup call seems to work for us:

$generatedUrls = $this->generateCategoryUrls((int) $storeId, $product, $productCategories);
// if ($isGlobalScope) {
// } else {
//     $generatedUrls = $this->generateCategoryUrlsInStoreGroup((int) $storeId, $product, $productCategories);
// }

From the original issue it said Urlrewrites are generated only to the storeview where changes where made and I fail to see how that isn't intended behaviour.

[iwanzijderveld]

Is there any idea when this will be fixed?

A rollback to how it worked before would suffice in this case right?