In _form_options_expand() there is the following code at the bottom:
// Remove properties that will confuse the FAPI.
unset($element['#options']);
$element['#required'] = FALSE;
Unfortunately, if I make an options element with #required => TRUE, this means that it gets set to FALSE. Only the manual textarea is set as required. But if I do not actually enter any key/value pairs in the options UI, it passes validation.
This is because _form_options_validate() checks $element['#required'], but because the module altered it to be FALSE, this condition never passes:
// Check if no options are specified.
if (empty($options) && $element['#required']) {
form_error($element, t('At least one option must be specified.'));
}
I'm wondering a bit why we can't actually just use the native #required property and what issues it actually causes. This has unintended side effects of missing required form indicators on the options element in the UI as well, which can confuse users.
Comment | File | Size | Author |
---|---|---|---|
#3 | options_element-1978820.patch | 344 bytes | quicksketch |
Comments
Comment #1
quicksketchThe problem in the past was that $element doesn't have a usable value by itself, since it's a nested array of values. I think what happened previously was that you would get the "Illegal option. Contact site administrator." because of #options being present, and #required would either never or always pass, I can't recall. However, I'm not sure that either problem still exists in Drupal 7; it's likely code that was ported from an earlier version and may not be necessary today.
Comment #2
Dave ReidWill try to tackle this next.
Comment #3
quicksketchWell I tried everything I could in both D6 and D7, but removing the #required property did not seem to have any negative effect, so I removed it straight-up. This brings #2114503: Duplicate key error message displays wrong to the surface more frequently though, we should fix that one at the same time.