Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
On a custom composite element created from a module you can add radios elements.
class MyCompositeElementWebform extends WebformCompositeBase {
...
public static function getCompositeElements(array $element) {
$elements = [];
$elements['Color'] = [
'#type' => 'radios',
'#title' => t('Color'),
'#options' => ['blue' => 'Blue', 'red' => 'Red'],
];
return $elements;
}
...
}
You overwrite the option from the YAML source, but if a site builder want to edit or add those options, it's not possible from the UI:
Proposed resolution
Provide an UI. A safe start could be to only allow overwriting the text of the existing option, like with the title of the element (so not adding extra option neither changing the key)?
| Comment | File | Size | Author |
|---|---|---|---|
| #18 | interdiff_13-18.txt | 719 bytes | gquisini |
| #18 | 3295420-18.patch | 5.31 KB | gquisini |
| #15 | composite-tests.png | 35.91 KB | gquisini |
| #15 | webform-composite.png | 18.64 KB | gquisini |
| #13 | interdiff_8-13.txt | 335 bytes | lucasbaralm |
Comments
Comment #2
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedWe can also address this via 6.1.x
Comment #3
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedComment #4
diegorsI will review this.
Comment #6
diegorsI tried to reproduce the bug, but as I don't know much about the module I wasn't able to create a custom composite element to test.
Comment #7
gagarine CreditAttribution: gagarine commented@diegors you need to create a custom module. Their is an example on https://git.drupalcode.org/project/webform/-/tree/6.2.x/modules/webform_... . Sadly I don't have the time to test this right now.
Comment #8
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedYou can the webform_example_composite.module for testing
Comment #10
lucasbaralmI will review this.
Comment #11
lucasbaralmGood Morning!
I reviewed the patch #8.
Steps taken:
1.Modified webform_example_composite.module to add the radio button elements.
2. Activate the Webform UI plugin to allow modification of the webform from the UI.
4. Applied the patch that creates the UI for modifying radio buttons.
5. Tested the UI, verifying that it saves the modified radio values and that it saves the new submissions entries with the new values correctly.
The created UI is working perfectly, but the two errors in the tests should be fixed before moving to RTBC as the branch passes tests without the patch.
Comment #12
lucasbaralmI will work on this.
Comment #13
lucasbaralmI fixed the issue that was causing a test to fail with the error "Warning: Array to string conversion" by changing a conversion from (string) $value to print_r($value, true), please review.
Comment #14
gquisini CreditAttribution: gquisini at CI&T commentedI'll be reviewing this one.
Comment #15
gquisini CreditAttribution: gquisini at CI&T commentedSo,
following steps #11 and using patch #13, everything worked successfully. I was able to overlay the radio options.
I also ran the functional tests on the /composite folder. I just had to install the address module to make everything work.
Comment #16
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedThe patch has some code styling issues that need to be addressed
+ elseif (print_r($value,true) === print_r($option_value,true)) {+ elseif (print_r($value, TRUE) === print_r($option_value, TRUE)) {I am also skeptical of using print_r() to compare values.
The original
(string) $value === (string) $option_valueis meant to allow Markup and strings to be accurately and identically compared.We might be able to use (and note in comments) a less strict equality
$value == $option_value@see https://www.php.net/manual/en/language.operators.comparison.php
Comment #17
gquisini CreditAttribution: gquisini at CI&T commentedI'll work on @jrockowitz suggestions.
Comment #18
gquisini CreditAttribution: gquisini at CI&T commentedSo...
WebformOptionsHelper::hasOption():
I tested equal and identical operator in a sandbox environment and did some debugging as well.
If we use the identical operator as it is in code, where it does the casting type and then compares the values or use the equal operator without the casting, it doesn't have much difference, so I kept the original changes.
WebformTokenManager::validateElement():
Same as above, I tested
!is_string()and!mb_strlen()in a sandbox environment and did some debugging.The
!is_string()only returns true if the variable is not of type string and the!mb_strlen()returns true if the length is zero. Since the variable is being taken from the element value or the element's default value. The type will always be string, so we just have to check if it is empty. So, again, I kept the original changes.Comment #20
lucasbaralmThe only problem is the test output, it fails and set a warning to "Warning: Array to string conversion" without the changes that i did. Maybe we should try another workaround?
Comment #21
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commentedI am inclined not to implement this feature and let it be handled via custom code or dedicated contribution.
I suspect this change will cause regressions.
Marking postponed to give people a chance to weigh in.
Comment #22
jrockowitz CreditAttribution: jrockowitz as a volunteer and at Webform module Open Collective, The Big Blue House commented