Magento2: store view takes wrong url key when using "default value"

[hezide]

Hi, I'm editing a product in two store views.
The first store view works fine but there is a bug I think in the second.

Preconditions

1. Magento 2 CE 2.1.4
   2 Two store views are created

Steps to reproduce

I think that in the past the URL KEY was different in the "all store views" but then I changed it.
In my example, the URL key in "all store views" is "red-dots-sack-bag"

1. Change to "English" store view (that's not the default store view).
2. Go to Search engine optimization.
3. Change URL-key
4. Check Use Default Value
5. Save

Expected result

1. Check box is checked and the value is "red-dots-sack-bag"

Actual result

1. The check box is not checked.
2. Value inside URL KEY is "sack-bag-red-dots"

[TommyKolkman]

I have this too and have been searching for a solution, nothing yet. Just to verify - it seems like this happens on products that we have imported via the M2 import function only. Is that the case with you too?

[luukschakenraad]

Same issue here. Seems checking "use default value" generates a new slug, based on the products name instead of inheriting it from the parent store view

[hezide]

@TommyKolkman No I didn't import any product...

[Tonop]

Have the similar issue,
1) checkboxes are not checked after checking and saving of any attribute.
2) Also the value for URL is based on product name of current store view but is not default (parent store view URL).

[magento-engcom-team]

@hezide, thank you for your report.
We've created internal ticket(s) MAGETWO-81627 to track progress on the issue.

[kllee824]

Hi,
Would like to know which table to save the different store_view to use 'use default value' 'Yes/No'? because i want to be update by SQL to enable this as my application is 'English/Chinese' store view and can't use common parent URL key when save the product

Lun

[patrick-bigbridge]

I have a temporary fix for this issue:
In MagentoCatalogControllerAdminhtmlProductInitializationHelper, function initializeFromData, below the comment /** Check "Use Default Value" checkboxes values */

replace the code there with

        /**
         * Check "Use Default Value" checkboxes values
         */
        $useDefaults = (array)$this->request->getPost('use_default', []);

        foreach ($useDefaults as $attributeCode => $useDefaultState) {
            if ($useDefaultState) {
                $product->setData($attributeCode, null);

// Fix: by setting url_key to false (not null) we prevent ProductUrlPathGenerator::getUrlKey() from creating a new url_key
if ($attributeCode == 'url_key') {
    $product->setData($attributeCode, false);
}

                // UI component sends value even if field is disabled, so 'Use Config Settings' must be reset to false
                if ($product->hasData('use_config_' . $attributeCode)) {
                    $product->setData('use_config_' . $attributeCode, false);
                }
            }
        }

The idea behind this is that, even though the function initializeFromData clears the url_key from the form, the url_key is later auto-generated from the name by the plugin ProductUrlKeyAutogeneratorObserver. This plugin checks if the url_key is false; if it is, it does not generate the key.

[cadencelabs-master]

See here for a patch: https://www.cadence-labs.com/2018/03/magento-2-use-default-value-store-view-scope-fix/

The associated module should fix the issue which comes from the url_key autogenerator (for url_key attribute) and then the general issue of attributes in non-opened tabs not having their "use_default_value" flag sent to the server

[luukschakenraad]

@magento-engcom-team Seems like you've already created a patch voor this issue (at least for Enterprise). Would you mind sharing MDVA-6515_EE_2.1.9_v2.patch here?

[m2-assistant[bot]]

Hi @engcom-Echo. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• [ ] 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 2. 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_!

• [ ] 3. If the issue is not relevant or is not reproducible any more, feel free to close it.

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[magento-engcom-team]

:white_check_mark: Confirmed by @engcom-Echo
Thank you for verifying the issue. Based on the provided information internal tickets MC-30042 were created

Issue Available: @engcom-Echo, _You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself._

[engcom-Charlie]

Hi @hezide,
We are not able to reproduce this issue on the latest 2.4-develop branch by provided steps.

Please could you take a look?

[hezide]

Hi @hezide,
We are not able to reproduce this issue on the latest 2.4-develop branch by provided steps.

Please could you take a look?

Hello,
For me the issue is not relevant anymore.
If no one else encounters it, you can close.

[engcom-Charlie]

Thank you for fast answer. So i've to close it.