Changes between Version 2 and Version 3 of Ticket #47692, comment 9
- Timestamp:
- 05/12/2020 05:20:38 PM (5 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #47692, comment 9
v2 v3 2 2 Also, I believe some developer confusion could come from the fact that "choices" expect the "value" as the property name, and the "label" as the property value (in the current class-wp-customize-control.php code). Wouldn't it be more logical for the "label" to the property name, and the "value" to be the property value? Like this: 3 3 4 5 {{{ 4 {{{#!php 5 <?php 6 6 <select id="<?php echo esc_attr( $input_id ); ?>" <?php echo $describedby_attr; ?> <?php $this->link(); ?>> 7 7 <?php … … 13 13 }}} 14 14 15 Then it would be much easier to check if "$value" is an array, and i f so"$label" would become the optgroup label and "$value" would be parsed for the options that fall under that optgroup label. There would be no need to set an "optgroup:true", it would be implicit when the value is an array of more "label=>value" associations.15 Then it would be much easier to check if "$value" is an array, and in such a case "$label" would become the optgroup label and "$value" would be parsed for the options that fall under that optgroup label. There would be no need to set an "optgroup:true", it would be implicit when the value is an array of more "label=>value" associations. 16 16 The same would have to apply to radio groups for consistency. Changing this would obviously break current setups that use these components. But it would seem more logical to me...