Labels for single on/off checkbox field aren't appearing

I've tried this in 4.7.x-1.x-dev and 5.x-1.x-dev and have the same problem.

Single on/off checkbox labels not appearing on my 4.7.6 site either..

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.

Here is a patch for the solution proposed above against the DRUPAL-5 CVS tag.

+1 for this issue too... it's causing me problems on a number of sites.
Thanks for the patch too.

here, too: +1 for this patch.

Now the Single on/off checkbox works as I had expected it to.

There are a few bus with the checkbox's that could include this issue see this posting

Additionnaly onoff option widget checkbox not respecting my 'default value' set in the CCK setup of this field, can anyone else confirm this?

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

+1 to both issues above
same bugs

oddly, the second of 2 default values is displayed as the label on the checkbox

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.

can you elaborate about this intended use?
for now, +1 for patch

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.

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.

For a 'Single on/off checkbox' widget, define the 'off' value first, then the 'on' value in the Allowed values section. Note that the checkbox will be labeled with the label of the 'on' value.

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.

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.

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.

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?

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.

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.

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.

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

Thank you for this explanation. Better help text at the top of the page would be nice.

--

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

See #3 and #4 above.

20 against 1, dude, and we're all using pbarnett's hack. programming ideals, poo... just fix the module lol.

+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.

It might be a cleaner solution to simply provide a 'Use label field as label' checkbox in the widget options ;-)

Pete.

In 6.x-2.0-rc4 version this module is the same bug.

Is fixed by editing on the 279 line.

18 months after the first post, and this is still a 'feature' :-)

Pete.

I don't really get how current behaviour (without patch) can be considered more consistent. Having a different label when submitting and when viewing a node seems counter-intuitive, inconsistent with itself, and inconsistent with Drupal's behaviour in general. I can see how it's more, erm dunno what the word is, transferrable or something, but it's in no way consistent IMHO.

I like #29, or something like it. Should this issue be turned into a feature request? Btw my original need has now vanished so it really has no impact on me ;)

Andy

Can we please fix this in core now? It's been too long in coming. The original implementation is clearly long winded and not obvious at all.

Seriously, this needs to be fixed yesterday. I am a newbie to Drupal (and an experienced programmer in other systems) who is perplexed by this behavior. In such a well-designed, user-friendly system as Drupal it seems ridiculous that a checkbox -- arguably the simplest form of control that a user can be shown -- could be this complicated to administer.

In fact, I actually consider this feature not just unintuitive, but broken for the following reason: There's no way that a value should serve as a label on the submission form. That's not a feature, or a designed behavior, that's a bug.

It makes no sense that, when a node shows up in a Views table as a search result, the column header's text is effectively the same as the "yes" value. As AndyF pointed out, you can make the label different from the "yes" value, but that's jumping through semantic hoops and results in wasted space onscreen and a lack of clarity for the end-user. Let's say I have a custom node field that tracks whether that node's attached file requires a MacGuffin to install that file. How many ways can you phrase that succinctly? Basically, two: "Needs MacGuffin" and "MacGuffin Required?" So you end up having to use the non-questioning version as the value and the questioning version as the label, because it makes no sense the other way around. So this is what you get when you view the node in a Views table as part of search results, etc.:

# MacGuffin Required?
1 Requires MacGuffin
2 No

So, one value is self-explanatory, and also redundant with that header there. Also, the "No" value now stands out like a sore thumb. We can't change "Requires MacGuffin" to "Yes", remember, since that makes a checkbox called "Yes" on the submission form. So inevitably we are led to this option: rename "No" to "Does not require MacGuffin", then turn off the displaying of the column's label in the Views table:

#
1 Requires MacGuffin
2 Does not require MacGuffin

Now the user has to read many times as much text to get the same information as a simple "Yes" or "No" could provide in answer to a column label of "MacGuffin Required?".

I understand that from a programmatic standpoint there was reason to set things up this way. But the programmer must bow to the end-user. The end-user is the one who matters. I bend over backwards for them everyday when I abstract my program designs from their appearances to make them more user-friendly, so things like this irritate me more than they do most people. For instance, here's what I'd do in this case. I know that the checkbox is a form of text field in Drupal, but that doesn't mean you have to tell the administrator that. Drupal is designed so even a stark newbie like me can easily configure it, so why does it get hard for me to understand here? Two reasons: just because the checkbox is text internally, the user should not be burdened with this awareness. I would make the initial Field Type menu show an option with the name of "Control" and put it in the menu right alongside "Text" even if they were technically two sides of the same coin. Now, even if that's not desirable here because it could confuse Drupal developers into thinking there's a new Field Type (I guarantee, by the way, that the confusion is always going to be greater on the side of the user who has to magically divine that a checkbox will be found under the "Text" option, and don't reply to this with "just read the docs" because we're talking about user-friendliness here, AKA "How far can the user get without ever looking at the docs?", not "Is it documented at all?").

But at least -- at the very least -- I would remove the whole "Allowed values list" nonsense from the equation. I know, I know, it makes the checkbox less compatible with the radio buttons. That doesn't really matter. As was already pointed out, having to re-enter all two or three pieces of related information when switching from one control type to the other is hardly an arduous, nor common, task. Really, we're talking about a Boolean-state control here; why provide a massive area to define a list of values? Just make three separate text fields that appear right at the top of the form when creating this control type: Label, On Value, Off Value. Don't inter-relate them or require any crazy pipe-value stuff. Please.

Maybe I didn't have to spell all this out when AndyF more or less did so already, but I signed up just to post this anyway. Since nothing has been corrected in any of the core revisions that have been made since the thread was opened one year and seven months ago, I feel like the developers don't agree with us on the illogic that's going on here. My apologies if I'm wrong, if they're already fixing this, or if I sound unappreciative of their work. But the solution should be quite simple and I think the problem is undeniable. What more do we need to say?

Amen!

Pete. (My original post, #2, was in Feb '07; see also #19 and #29)

A strange and puzzling update to my situation: I seem to have accidentally fixed the problem, at least on my own Drupal site. I now have the Label set as "MacGuffin required?", and the allowed values set as "no|No" and "yes|Yes", and yet the column header for Views (which can be renamed, by the way) automatically supplied "MacGuffin required?" and the submission form also shows "MacGuffin required?" So now all text is the way it should be. Huh.

If it was even remotely possible for me to retrace my steps, I would write them out there. But because I changed the allowed values so many times, as well as changing other settings back and forth in Views and Drupal core, I have no idea what happened. Every time I changed a setting, I checked the Views table and the submission form, and nothing seemed to work, until suddenly it was working for no reason while I wasn't paying attention (pardon my fogginess, but I have been plugging away at the site most of the day and this was just one of the issues I was working on). It almost seems to be a beneficial bug, where some text did not refresh internally in a cache somewhere.

I will only mention what I clearly remember, which is that that I made no module updates except to unrelated modules (updated TaxonomyList and installed Plugin Manager (and no, PM did not install any updates, it broke before it could and then I disabled it)). I also emptied my browser's cache for an unrelated reason, but I do not know if it was before this situation fixed itself nor can I imagine why emptying Firefox's cache would have any effect on this situation at all.

P.S.: And by the way, I know that the allowed values could be set to simply "No" and "Yes"; the pipe values should be unnecessary. Do you think I'm going to play around with that now? No way. Nothin' doin'. I'm staying as far away from these settings as I can, lest I tempt fate to put things back to the way they were.

Only a haiku would suffice :-

First it was broken
Now it works for no reason
Drupal is like that

Pete.

It is now over two years since this thread was first posted. I am forced to post a comment because I have been working on a content type which was supposed to allow the user to view and edit check box fields (ie turn them on/off). Both AndyF and Iritscen agree that the behavior of the implementation of on/off check boxes in the CCK modules is not Drupal like.
I will go further.
It is GUI like.
It is not check box like.
I would say that CCK does not really provide a true on/off check box widget to support boolean field type.
The allowable values list is really a feature of list boxes and indeed a list box with only two allowable values (true/false, 1/0 or yes/no) could be used instead to achieve the same result.
You cannot even see check boxes in node view instead you see only text from the allowable values list.
All the strange behaviors mentioned in this thread I discovered while working on my site resulting in several surprises and my spending several days to do what ought to have been done in an afternoon. Yet at the end of it users only see check boxes while editing a node with the wrong label!

Could we get genuine support for on/off check boxes widget in CCK? .............. Please!

As I said in #3, changing

Pete.

Since this discussion seems to be generating more heat than light, could we not simply have a configuration page where this behavior can be toggled between the label and the on value?

Pete.

amen

I have the same problem and Pete is right.

With CCK 6.x-2.2, at file cck/modules/optionwidgets/optionwidgets.module, version v 1.69.2.23:

At line 291
'#title' => isset($options[$on_value]) ? $options[$on_value] : '',

we can change to

'#title' => $field['widget']['label'],

It's a good idea have a option to define how to print the check box.

Thank's Pete!

Can we ever just fix this module? This is by far the biggest problem with CCK right now. It is the fly in the proverbial ointment. The problem is not that it is lacking documentation; it is that we can not get it to act as it should. The solution in #40 is perfect.

I'd really like to see this get in there. It's keeping me from using that widget altogether.

For all (like me) that were going crazy about this, just enter the following in the allowed values textarea:

0|No
1|Your Label Text

Because the value for "1" is what gets displayed next to the checkbox.

That being said, I think it's a usability bug that the label seemingly does nothing for this field, and I still think a patch is in order. Moving to "active"...yched, feel free to put back to by design if you still disagree.

Thanks for the great fix in #45. That works as I would have expected the module to originally work...

I wouldn't call this critical, but still needs to be changed IMO.

After 2 and a half years, I wouldn't hold my breath whilst waiting :-)

Pete.

+1 for getting this fixed for what it's worth. I'd say it's critical, as for me the single checkboxes are unusable without a fix in there.

The problem with 45 is that when you display the node the Label gets used as the display value.

Solution in 40 would be perfect, is there any will to commit a patch that won't break old sites?