Magento2: Can not update configurable products, price of simples suddenly become 0,00

[tempo-ruud]

Preconditions

1. Magento 2.1
2. Nginx
3. PHP 7.0.9
4. Memcached

5. Redis Server

   Steps to reproduce

6. Add a new configurable product

7. Create the simple products while creating the configurable product
8. Save the product
9. Open the configurable product again
10. Upload images or change any other data

11. Save the product

    Expected result

12. Configurable product get updated

13. Simple products related with the configurable product should stay the same

    Actual result

14. The simple products suddenly have the price of 0

[tempo-ruud]

I even disabled all installed modules and that did not help

[heldchen]

same here. we use an adminlogger extension, which logs all actions. when the configurable parent is edited, children are updated after saving. the update changes price (sets it to 0.00) and the configurable_attribute fields of all associated simple products. this is unbelievable devastating as now the products are orderable for free.

[tempo-ruud]

@duhon can you give me any update on how much time it will take before this gets patched. We have a huge issue with this as we want to create a lot of configurable products.

There are now 2 big issues on the configurables that cost us way more time than before. The second one is that we can not select existing simple products on a newly created (configurable) product.

In my opinion these bugs are to huge for a master branch.

[duhon]

@tempo-ruud I'm trying to reproduce the problem, but I have everything working. You can help me. Have you reproduced the problem without Memcached and Redis?

[tempo-ruud]

@duhon Nope, both are enabled right now, but if you wish, I can give you access to my webserver and Magento admin, so we can figure it out together.

[heldchen]

no memcached here, no redis either. magento 2.1.0 in developer mode on local dev machines. we're using 2 frontend store views (DE + FR) and seeing the error when editing the configurable product in the default storeview.

[tempo-ruud]

I only have one storeview enabled

[duhon]

I still cannot reproduce this issue.
Please also describe all steps you have done in a more detailed way and if you can attach the screenshot or some logs it may help as well.
If you are using EE version, contact support.

[duhon]

@heldchen are you using a clean installation without any additional settings?

[heldchen]

here's a screenshot of one of the examples logged by the adminloger extension (bottom to top):

the user was editing the product parent product 31604. upon saving, its stock item was saved (15832), then the product (31640), then the configurable attribute, and then all the child items stock item and product. the stock item kept their values, but the product update set the price to 0.0000. see for example child product 31601.

all products were imported/created in 2.0.2 or 2.0.3 and and thereafter upgraded in all the following releases up until 2.1.0.

as for the question regarding "clean installation": we started clean except for the products-related data which was imported quite early in the process through csv imports.

I can try to create a small db dump containing just some of the broken products if that helps?

[heldchen]

I played around a bit more with it. it only seems to happen the first time a parent product is saved after upgrading to 2.1.0. later saves of the parent product do not affect the price of children anymore. @tempo-ruud is that the same on your system?

[tempo-ruud]

@heldchen Nope, for me it is a clean setup of Magento 2.1. I only installed a theme. After the installation of the theme I imported a csv with only simple products. This did not seem to work as there where a lot of configurable products in the shop and they shop admin could not assign the simple products to a newly created configurable product.
So the admin is now creating the configurable products manually. But after he created them and edit them again he has a problem with the prices, images and seo values as they become empty.

[heldchen]

yeah, that sounds like the exact workflow as we did after initial product import - the customer only had simple and grouped products in the old shop but wanted some of them as configurable products in the new shop. so the show owner manually created the configurable parent products, whereas the simple child products were imported through csv.

[tempo-ruud]

@duhon did this help you reproduce the error.
By the way, if you wanna know which server config I am using. Here is a link to the repo:
https://github.com/magenx/Magento-Automated-Server-Configuration-from-MagenX

[tempo-ruud]

@heldchen did you already fix this. I also posted the question on stack overflow as I get really crazy of this. What ever I try I cannot fix it.

[paales]

Experienced this as well after having products imported.

[tempo-ruud]

Thanks @paales for confirming

[heldchen]

@tempo-ruud for our system, the values are 'only' resetted once - after correcting the values, further saves of the parent product are not affecting the childrens anymore. are you making the same experience?

[tempo-ruud]

@heldchen no we have the problem each time we save the product.

[oserediuk]

Hello @tempo-ruud ! Did your modify imported simple product after import? How you assign simple product to configurable? Which attribute do you use for this?

[oserediuk]

Hello guys! Do you all use nginx?

[tempo-ruud]

@oserediuk Yes I use nginx, I use this server configuration: https://github.com/magenx/Magento-Automated-Server-Configuration-from-MagenX

[heldchen]

@oserediuk we only imported simple products and manually associated them to the parents. apache2 / php-fpm / 7.0.8

[oserediuk]

@heldchen which attribute type do you use for configurable options?

[tempo-ruud]

@oserediuk We only imported simple products with the csv imported that is default in Magento 2.
After that we wanted to assign the simples to configurables, but this was not possible in Magento 2.1 so we created manually the configurable products with newly created simples.

[tempo-ruud]

@oserediuk we use the attribute size for the configurables, if you want I can give you ssh access and admin access so you can check it on our server

[oserediuk]

@tempo-ruud It could be useful) Send credentials, please, to my email [email protected]

[heldchen]

@oserediuk several: size, color, weight, ... depends on the products. around 10 attributes are configured to be configurable out of 120 custom product attributes.

[heldchen]

@oserediuk according to our client's content manager, some (all?) of the affected configurable parent product had a temporary attributeset that later got switched to a final attributeset

[tempo-ruud]

@heldchen @oserediuk That was not the case with us.

[tempo-ruud]

@oserediuk Isn't it an option for us to downgrade to the newer version 2.0.9?
If yes, how can we do that.

[oserediuk]

@tempo-ruud could you provide you csv import file that you used?

[tempo-ruud]

@oserediuk yes it is in your mail.

[JamboMedia]

Same problem here on Magento 2.1

The problem only occurs in the custom user role our client use. The prices of the simple products are going to 0.

In the admin role it works without a problem.

[tempo-ruud]

wow that is an amazing suggestion, didn't think about that
but some users indeed have a custom rule.

[tempo-ruud]

Nope that was not the issue, everyone has the admin role with me...

[JamboMedia]

OK, in the admin role it works at our side. Only on a custom role it goes wrong.....

Hope there is a solution fast

[tempo-ruud]

I just tested it with giving the product management my user account and than it worked perfectly. So what I see that it works on the account that installed Magento and any additional account it does not work correct.

[JamboMedia]

Excactly the same at our side!

[heldchen]

same here! our customer's content admin users are restricted. that also is the reason why I couldn't reproduce it properly. awesome find, @JamboMedia

[tempo-ruud]

Kudos for @JamboMedia

[tempo-ruud]

@heldchen @JamboMedia Came one step closer. The admin account is in en_US, but the other accounts are in nl_NL. When I change the other accounts to en_US the error also does not occur.

As I noticed that @heldchen is from Switzerland I guess they can have accounts in German or French.

@heldchen @JamboMedia Can you both check if this is also the issue on your side?

[tempo-ruud]

@oserediuk the statement above sounds logic if you think of the fact that Mage2 has huge problems with JS translations. Already have some clients getting mad at the fact that I can not translate stuff that is really necessary. Think of the checkout.
I think the whole JS translation part is a huge bug for which you guys need to find a solution soon, as right now I have to change core code _cursing for a developer_

[heldchen]

@tempo-ruud yes our content managers use a non-en_US locale, restricted account for the backend, whereas I use the default locale with admin rights. I'll do some debugging later today.

[tempo-ruud]

and for you @JamboMedia I guess you are using Dutch or not?

[heldchen]

account restrictions are irrelevant. i changed my en_US account to de_DE, edited a configurable product, now the children had their values reset.

quick fix: change all users to en_US :(

[tempo-ruud]

@heldchen glad that I could help you with the quick fix. anyway it is an annoying bug

[paales]

Ahh, so this issue seems somewhat related: https://github.com/magento/magento2/issues/5745

[peec]

We're experiencing same issues. Needs addressing and patched fast. Configurable products are very essential.
Magento 2.1.1 CE.

As a development company. We have created nb_NO language for admin language. Also we are planning to create documentation for the admin panel, so our customers can use admin in a familiar way. Right now, we can't deliver magento 2 solutions because of this.

What this means for us,

• We cant use configurable products.

EDIT: Did not formulate my self clearly. Tried again.

[heldchen]

@peec the admin language is completely unrelated to the frontend storeview language. our frontends are de_CH and fr_CH and yet our content admins are now using en_US. after all, the admin backend language only determines the translation used in the backend. the prices entered in an en_US language will still show up formated to your nb_NO locale in the frontend - they are not stored as strings in the database.

[tempo-ruud]

@heldchen yes but there are still people that can not speak english.

[heldchen]

sure, but that's a different reason than "We use nb_NO language for admin, since that's what our customers are going to use. So changing to en_US will not work for us."

and honestly, the few english terms needed to create/edit products are managable until this bug is fixed.

more worrysome is that the magento devs have not yet been able to acknowledge this problem due to being unable to reproduce it...

[AVoskoboinikov]

Hi guys!

I am trying to reproduce your issue and have some questions that I need to clarify.
Have you any installed language packages?
Can you reproduce this issue with new simple + configurable products or only with old?

Thanks

[tempo-ruud]

@AzVo For me I have this language package installed: https://github.com/Adwise/magento2-nl_NL-language
I have setup a new webshop with new products, so I can not say if it happens with old ones as well.

[peec]

@AzVo

We have created our own custom language package module ("magento2-nb_no"). Basically consist of:

• composer.json
• language.xml
• registration.php
• nb_no.csv ( large csv with 8000 lines of translations ).

How I managed to reproduce this:

1. Create a new configurable product with some simple's that has some custom prices.
2. Save the configurable product.
3. It seems that now the prices are OK.
4. Try to go into the configurable product, edit it. And save.
5. Now the prices disappears.

When we switched admin language to en_US we didn't have the problem.

Our environment:

• Nginx
• PHP-fpm + php 7
• Mysql 5.6
• Magento 2.1.1 CE
• Magento env: prod
• Cache settings: memcached
• Session storage: db
• Filestorage: filesystem

[JamboMedia]

Excacly the same for us. We added a dutch language package.

On admin language en_US the problem isn't there.

[heldchen]

yes, we use de_CH and fr_CH. when one of those is used for a backend user, the data is corrupted - therefore en_US for now in the backend.

[tempo-ruud]

@heldchen Offtopic: I was wondering, for which company do you work in swiss?

[heldchen]

@tempo-ruud sent you an email, I don't want to use github for "advertising" :)

[AVoskoboinikov]

Hi guys!

I've managed to reproduce this issue, so I created internal ticket to fix this (#MAGETWO-58209). This issue will be closed after fix.

Thanks to everybody for reporting and investigations!

[heldchen]

awesome, thanks for your time!

[Pagayo]

This simple fix saved me today 👍
Hope it get fixed soon, not every Dutch merchant reads English that well.

[tempo-ruud]

@Pagayo glad that I could help you with this.

[tdgroot]

Switching the Interface Locale back to en_US worked for me, this is a great temporary fix!

[ghost]

Thanks for this, also a dutch user :-)

[jurgenbrouwer]

Can you provide any update on this issue @AzVo ?
We ran into this as well using another language in the backend. For now we can use the English language in the backend since we are still developing.

[SolsWebdesign]

Yes, thanks (another Dutch user)...

[hansvanl]

Would love an update also.

[ghost]

I have the same problem with the Dutch language pack.

[mike-happy]

Is this issue fixed in Magento 2.1.4?

[veloraven]

This issue was fixed in develop branch in scope of internal ticket MAGETWO-57279
Internal ticket for ver. 2.1 - MAGETWO-58518

[magento-engcom-team]

@tempo-ruud, thank you for your report.
The issue is already fixed in 2.2.0