This module has code that prevents the options element's default value from being edited if the existing #default_value is set to FALSE. With #1092756: Unable to not have a default option for mandatory radio button group with a key of 0 recently committed to Webform, this breaks things in the situation where you have e.g. radios or selects configured to not have a default value (because that patch sets #default_value to FALSE in those situations).
To reproduce, just create a webform with a radio or select component and edit the options so that there is no default value, then save the webform and edit it again. Within the Options Element interface, there is no longer a way to configure the default value.
It looks like the code in Options Element that allows the default value UI to be hidden is there intentionally (I'm not sure what the use case is exactly, but I guess there is one). So, this patch just adds a new key called #manual_default_value_allowed that can be used to decide if the UI should be hidden instead. This way we don't overload the meaning of #default_value = FALSE, which already has way too many other meanings in Drupal :)
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | options_element_default_enable.patch | 1.33 KB | quicksketch |
| options-element-manual-default-value.patch | 1.35 KB | David_Rothstein |
Comments
Comment #1
quicksketchThanks, I removed the "manual_" part from the key, since it didn't really have any meaning. The property is now just called "#default_value_allowed". I couldn't actually reproduce the problem you're describing, but considering the recent changes to Form Builder, plus the differences between Acquia's Form Builder and the contrib one, it could easily been caused by a code difference.