- Issue created by @AaronBauman
- 🇺🇸United States AaronBauman Philadelphia
OK, i traced the culprit to
commerce_product_update_10301
, which according to docblock :/** * Moves 'variationType' setting to the 'variationTypes'. */
Problem was that my "variationType" was set to "default", but "variationTypes" was set to "shippable" (and shippable only).
So, after updating, "variationType" is gone, and variationTypes is "default" and "shippable" - not what i want!
And since it's a simple inline entity form, I guess it just uses the first value, which is not correct.Not sure how this was resolved previously, but turning "default" off again solved it.
- 🇺🇸United States AaronBauman Philadelphia
Here's the patch I'm using.
I assume maintainers are not gonna want to roll this in, so I won't bother with an MR.
But it's working for me. - 🇮🇱Israel jsacksick
hm, no this change doesn't make sense? I think what we should probably do instead is not touch the variationTypes if it is set... Can you open an MR doing this?
We only migrate the values if variationType is set but variationTypes is empty? - Merge request !469Issue #3535297 by aaronbauman, jsacksick: The variationType setting migration... → (Merged) created by jsacksick
-
jsacksick →
committed 58f63e7a on 3.x
Issue #3535297 by jsacksick, aaronbauman: The update hook for migrating...
-
jsacksick →
committed 58f63e7a on 3.x
- 🇮🇱Israel jsacksick
Went ahead and committed the amended update hook which now sets the variation type IDS only if the "variationTypes" setting is empty.
- 🇺🇸United States AaronBauman Philadelphia
Thanks, that change makes sense to me and should address my use case.
Not sure how or why variationTypes and variationType contained different values previously, but this should fix it.