Labels for single on/off checkbox field aren't appearing
jsenich - February 1, 2007 - 16:08
| Project: | Content Construction Kit (CCK) |
| Version: | 5.x-1.6 |
| Component: | optionwidgets.module |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | by design |
Description
I just installed the new version of cck to play around with and noticed that the labels for the new on/off checkbox field are not showing up for my new content types.

#1
I've tried this in 4.7.x-1.x-dev and 5.x-1.x-dev and have the same problem.
#2
Single on/off checkbox labels not appearing on my 4.7.6 site either..
#3
Hi again...
I looked at the code in optionwidgets.module, and found that the code was written to use the 'on' value of the checkbox as a label, rather than the label field.
This seemed a little counterintuitive to me, but it was clearly intentional.
I made a temporary fix by changing
'#title' => $options[$on_value],to
'#title' => t($field['widget']['label']),at optionwidgets.module line 125, but I guess we need the developers to clarify how this should work...
Pete.
#4
Here is a patch for the solution proposed above against the DRUPAL-5 CVS tag.
#5
+1 for this issue too... it's causing me problems on a number of sites.
Thanks for the patch too.
#6
here, too: +1 for this patch.
Now the Single on/off checkbox works as I had expected it to.
#7
There are a few bus with the checkbox's that could include this issue see this posting
#8
Additionnaly onoff option widget checkbox not respecting my 'default value' set in the CCK setup of this field, can anyone else confirm this?
#9
I can confirm both that :
labels are NOT appearing for single check box cck fields
default values are not being honored for single check box cck fields
I have applied no patches and am currently running on Drupal 5.1 with Content 5.x-1.5
Dave
#10
+1 to both issues above
same bugs
#11
oddly, the second of 2 default values is displayed as the label on the checkbox
#12
The is the intended behaviour of the 'single on / off' widget.
The CCK 1.6 release should have a help text a little more explicit about that.
#13
can you elaborate about this intended use?
for now, +1 for patch
#14
The intended but confusing behavior is still present in 1.6. I can't figure out how to make it work without patching, so can anyone explain? I'd like a checkbox called "Display in Sidebar" that sets a field value to an integer value of 1.
#15
I finally figured it out after seeing the help text in the 5.x-1.6 release, although I haven't tried it in the 4.7 version for which I originally had the confusion.
So here's what you would do:
1) Add a Single on/off checkbox integer field.
2) Don't worry about changing the "Label" field since this does not does not have anything to do with what is displayed as the label.
3) Enter the following two values in the Allowed values list:
0|do not display
1|Display in Sidebar
Now when you go to create content page for you content type you should have a checkbox with a "Display in Sidebar" label.
#16
Right :-)
And just for the info - the reason behind this unintuitive behaviour is this lets you change the widget back and forth between Radio buttons and Single Checkbox, while keeping the expected format for 'Allowed values' unchanged.
#17
jsenich - thank you for the solution
yched - I agree as a programmer, but as a user IMHO it's not obvious and should be explained ...
Jacob.
#18
This is a very odd behavior I would personally like to see changed in a future release.
I'm not reopening it because it would likely break sites but a single checkbox is nothing like radio buttons. There's just one with one label so why would you expect the same behavior?
Plus, who is going to switch back and forth between a single checkbox and radios on a regular basis. Isn't it almost as likely the would switch back and forth between a text field and a single checkbox? CCK isn't made for that sort of behavior so why should you cater to it at the expense of ui usability?
#19
Yeah; a year down the line and I still have the code modification I originally suggested in place; as a programmer myself I can see the point about consistency, but when adhering to that principle results in a tool that's counterintuitive to use, it's consistency from a programmer's point of view, not a user's.
In my experience, that's a Bad Thing...
As you say, when is anyone going to switch between a single checkbox and a radio button casually?
When do you use a single radio button?
If you change a set of radio buttons to checkboxes, you're going to have to restructure your code anyway, particularly if you're going to create a query using the form values, as you'll get a set of options rather than a single choice.
Whatever.
I've changed my copy, and don't have that much of an axe to grind...
More to the point, I don't have users having to read special instructions because the tool isn't intuitive to use :-)
Pete.
#20
jsenich: Thank you for the solution. It worked for me.
yched: I agree with you. It's not friendly user. It needs to be simplify.
#21
Agreed. This is very confusing behavior. It is nice to be able to switch from checkboxes to radio without having to change your allowed values, but in all honesty, a novice user is going to check the data when switching widgets before they would ever expect this strange and unique functionality.
The label field when creating the field should be the label showed beside (or above) the checkbox, not some unusual exception that uses the label of the data.
#22
Hi,
I just found this thread. Here's the behaviour which I'm finding impossible to work around.
a) when submitting a node the final allowed values label is used to label the checkbox.
b) when viewing a node, the normal label is used as a label, and the allowed values label is used as the value.
For my site I want to have a Job Posting content type. One field represents whether the position is as a team leader or not. My original thought was to have the following.
label: Team leader
values:
n|no
y|yes
This looks all screwy on the submit new node screen (for the reasons mentioned on this thread - it uses yes as the label). I can use the help text, but it still would look better with a real label above. Now if I change it as follows things look better.
label: Team leader
values:
n|no
y|Team leader
But now the problem is that when viewing the node it doesn't look right. Ie if the checkbox is ticked, it will display Team leader: Team leader, and if unticked Team leader: no which just doesn't look nice. The only alternative I can think of is like this.
label: Leader status
values:
n|Not team leader
y|Team leader
This just about works, but it's horribly nasty! Am I being stupid here? All I want is to have (roughly) the same display when submitting and when viewing nodes, and I want a simple way for binary on/off values without displaying both values simultaneously. Is this still by design?
Andy
#23
Thank you for this explanation. Better help text at the top of the page would be nice.
#24
--
#25
Andy F, I could not agree more! You explanation is exactly the same issue I am facing. I am just looking to implement a "boolean" type field where the defined label is shown no matter what the status of the checkbox (on or off).
- DTG
#26
See #3 and #4 above.
#27
20 against 1, dude, and we're all using pbarnett's hack. programming ideals, poo... just fix the module lol.
#28
+1 for using the "label" field as the label. If not, this will continue to be a problematic (and time wasting) widget for all new users.
#29
It might be a cleaner solution to simply provide a 'Use label field as label' checkbox in the widget options ;-)
Pete.