Unable to set different custom option labels for multiple store views

[mktudock]

Preconditions

1. Have Magento 2.1. (with PHP 7)
2. Install the sample data and create a new store view
3. Go to any product and create a custom option as a dropdown with some options (for global)

Steps to reproduce

1. Switch to another store view
2. Change the name of the custom option and the name of the values
3. Save

Expected result

1. The global scope and the store view should have different values

Actual result

1. The global scope and the store view both have the label / option labels of the store view

This is not related to the old display bug, it's actually possible to set the values for different store views, but they don't get saved correctly.
This is a critical issue for us, sadly because we need to be able to translate custom options.

[antboiko]

Hi @mktudock , thanks for reporting this. We already have internal ticket MAGETWO-47698 to fix this issue.

Best,
Anton.

[mktudock]

@antboiko Can you tell me how high the priority for these custom options issues is?

Because for us all of these issues (#5885, #5612, #5931, #5938, #5972...) are pretty critical for us. We have a shop that relies on custom options, and the 2.1. update made it pretty unmanageable.

Do you know when they will be fixed in the develop branch? Is someone already working on it?

[janhelleman]

This is a crucial part of Magento, why is this open since 29th of July without any information whatsoever? Issue 5612 since 13th? Where can we see this internal ticket? Since this ticket is obviously not being updated?

[mktudock]

I also want to point out again that ALL of these issues have the same core problem:

The custom options get deleted and recreated with new ids on save. For this ticket this means the translations get removed because new custom options are created that only contain information from the store view they were saved in .

(eg. You edit the option for german store view and on save a new custom option with only the german label get's created, since only the data for the german store view exists in the save request).

I'm pretty certain that if you revert the behaviour back to 2.0 all of these issues will be gone. Stop recreating custom options! Update them instead!

[JonasNeunzig]

Hi, we urgently need to translate our custom options to different languages, this bug wasn't fixed in 2.1.1. Could you please provide any information regarding the progress?

[antboiko]

Hi @mktudock , sorry for the delayed response. Please let me inform you that we're working on getting this issue fixed in one of nearest patch releases.

Best regards,
Anton.

[EmilyPepperman]

@antboiko I sure hope the devs can resolve this issue soon. Our new M2 site's launch depends on this working. Most of our products so complexly setup in M1 will not work on our M2 site. We were hoping to launch soon... but this issue alone will delay our launch.

[commcad]

We have launched our store but these configurable products issues/bugs are adding 600% more listings to our store :/ Currently; we simply block search engines to access and/or index our store for the time being.

SEO killer if used "as-is" (2.1.1). In our case anyway

@EmilyPepperman @antboiko

[antboiko]

Hi @commcad , can you please report the issue you're facing with configurable product in a separate ticket so we will be able to check it and investigate?

Thanks,
Anton.

[commcad]

@antboiko
This was reported a few times already. Can't find all the ref but here goes an example: #5938

[antboiko]

Thanks for the link @commcad. We're working on that one as well. It should be soon available in a mainline and furher in one of nearest patch releases.

Thansk,
Anton.

[janhelleman]

I don't want to pressure or anything but is there any form of estimate? We have multiple projects that depend on custom options heavily and right now everytime a product is saved things are rendered "useless". We can't estimate if we should roll out a custom fix ourselfs or wait for you guys to do so, and I guess others have similar challenges.

Thanks,
Jan

[Userr017]

This not yet resolved? I updated new magento 2.1.8 version and same problem. Anything quick fix?

[audexpro]

I upgraded from 2.1.7 to 2.1.8, but since the upgrade, the problem persists!

[HedonieBrazil]

Is it solved ? answer are not clear for me.

found pluging than can avoid the bug. but it is $299....

[HedonieBrazil]

i found the solution to the bug here : #8251

[magento-engcom-team]

@mktudock, thank you for your report.
The issue is already fixed in 2.2.0

[vkmunjpara]

Hello There,

I want to update just these two issues #2908 and #5885 (current page) to magento version 2.1.3. I don't want to upgrade whole version at this moment.

These two issues have been closed and resolved in 2.2.0. So can any body help me how to find the files for these two issues only from git hub ?

I saw commits in these two issues. Is there any quick method to get zip of commits for these issues only ?

[vkmunjpara]

@gemscng , @magento-team, @magento-engcom-team , @mmansoorebay

Hello Guys,

Please check my above comment. Can you please help me in this regard ?

Thank you..

[korostii]

@magento-engcom-team

You're saying it's only fixed in 2.2.0, while at the same time issue gets moved from TODO to Done in branch [2.1-develop]. Seems quite confusing.

Please clarify the status of this issue and the related internal ticket MAGETWO-57153.
Also, which 2.1.x version is expected to have this issue fixed, exactly?

[gemscng]

@vkmunjpara sorry that i have miss your message. You may check my forked repo and cherrypick those related to MAGETWO-57153. Just search MAGETWO-57153. Since i am using 2.1.5 so i am not sure if it can be applied to your version.

However, i strongly suggest you upgrade your project to 2.1.5 since most of our project has been upgrade from 2.1.2 to 2.1.5.

[tuyennn]

For those ones need to have it on your 2.1.x store. Use this patch
https://gist.github.com/tuyennn/77c3308b54b9abb7a907429c50166b6d