Closed (fixed)
Project:
Commerce Core
Version:
8.x-2.x-dev
Component:
Product
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
12 Dec 2018 at 23:10 UTC
Updated:
13 Feb 2019 at 00:24 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
jnrfred commentedAttach is patch to add a setting to widget.
Comment #3
jnrfred commentedComment #4
mglamanNeeds config schema update.
The default setting value is FALSE but we're checking 0.
Comment #5
jnrfred commentedConfig schema updated and changed default settings value.
Comment #6
deaom commentedI applied the patch, it applies, but when I do drush entup nothing is updated, the same with the drush updb.
When I go to the commerce configuration for product variation types after I cleared all caches, in the manage form display, I seem to not find/see the widget. I also tried adding a new field, still no luck with the widget. Maybe it's located somewhere else?
Br,
Dea
Comment #7
mglamanIt adds a setting to the existing attribute selection widget on the order item purchased entity field. Check there.
Comment #8
deaom commentedThank you for the guidance @mglaman. I found the widget and the add to cart button is present on the product. But I don't see the change when I disable or enable the widget on the default display or on the add to cart display. I have just one color available for a product and it is always shown, no matter what the widget says. I'm probablly doing something wrong here or the code is not working properly for me.
BR
Comment #9
deaom commentedComment #10
cornifex commentedSteps to Verify
Result
Before


After
Comment #11
bojanz commentedThe setting name has no relation to the label, and both feel odd (the description has a double negative, which takes a second to process).
Comment #12
bojanz commentedDiscussed with the team, we said that we should test to see if we can just remove the disabling completely. Don't even know if ajax is still triggered by a single option element.
Comment #13
rszrama commented+1 from me; disabling the form element is a bit of a hack here, simplifying form processing (i.e. we can safely disable it b/c a required single value element will have its value populated in the form state regardless) at the expense of visual changes on the front-end (the grayed out disabled element). Presumably we can disable the Ajax listener on the element if unnecessary Ajax refreshes is a problem.
Comment #14
bojanz commentedComment #15
bojanz commentedLet's try this patch.
Confirmed that it doesn't trigger #ajax.
Comment #17
bojanz commentedTests are green. Committed.
Commit credit goes to jnrfred, for his earlier efforts.
Thanks, everyone!