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

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.

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

<?php
        case 'options_onoff':
          // Display only the 'On' value of $options;
          $vals = array_keys($options);
          $on_value = $vals[1];
          $form[$field['field_name']]['keys'] = array(
            '#type' => 'checkbox',
            '#title' => $options[$on_value],   // <== THIS LINE
            '#default_value' => ($items['default keys'][0] == $on_value) ? 1 : 0,
            '#return_value' => $on_value,
            '#description' => content_filter_xss(t($field['widget']['description'])),
            '#required' => FALSE,
          );
?>

to

<?php
        case 'options_onoff':
          // Display only the 'On' value of $options;
          $vals = array_keys($options);
          $on_value = $vals[1];
          $form[$field['field_name']]['keys'] = array(
            '#type' => 'checkbox',
            '#title' => t($field['widget']['label']), // <== HERE
            '#default_value' => ($items['default keys'][0] == $on_value) ? 1 : 0,
            '#return_value' => $on_value,
            '#description' => content_filter_xss(t($field['widget']['description'])),
            '#required' => FALSE,
          );
?>

fixed it for me; this is the 5.x optionwidgets.module,v 1.10.2.13 2008/09/03 13:45:05 yched

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?

Please fix this. It woult take 5 seconds to fix it.

Could this be fixed in the 3.x branch?

Temporarily marking as critical to get module maintainer's attention.

1) This issue does not belong to the scope of CCK3. If at all, it should be worked out for CCK2, and we'll port to CCK3 as well.
2) It is not critical as it doesn't prevent CCK from running and it's been here for ages. Many sites are using on/off widgets as they are.
3) It is not even a bug. See comments #12 through #16. on/off widgets work as they were coded to work.

Now, if someone wishes to change anything in current implementation is welcome to write a patch for review. Anything here needs to be backwards compatible. Otherwise I suggest writing a separate widget for Number fields in contrib.

I find it ironic that people spend hours and hours struggling to merely understand this issue, yet they claim it should only take minutes to fix. I've learned to deal with it. That's what themes are for, right?

Back to "by design", at least until there's a patch for review that doesn't break existing sites. Otherwise, I suggest a new widget for Number fields in contrib.

This is working as it should (atleast working for CCK 6.x-2.5). Thanks to Iritscen (post #36) for hint.
Just put your values in two row (first should be negative) and it will work.
I used like:

[negative value]|[label]
[positive value]|[label]

my values was:
no| I am not agree
yes| I am agree

Umm...I feel rather stupid to ask any further question but here goes.

I've followed the advice given with the two values in the Allowed Values list but of I don't check the box, the content being published is whatever value I may have used for the first value ie: "do not display" is published on the site...

Anyone else experienced this?

Stewbirch / #57 :
I am seeing the exact same thing. It totally bugs me, because as far as I know EVERY other CCK field is nice and respectful of the idea "if you're empty, don't display". And yet here is my checkbox, displaying "0" in the middle of my page. Bah.

I give up on this.

Two radio buttons in the widget config to set a boolean variable that the code could check to conditionally implement the solution in #3 (as proposed on February 13, 2007) would do the trick.

The default, if the variable didn't exist or wasn't set, would be what the code does now.

I suppose I could write a patch for this; I'm just too busy at the moment :-(

As I said earlier, this discussion is generating more heat than light.

Pete.

I agree whith the people: actual approach is counterintuitive and confusing.

It's hard to believe that this *still* has not been remedied... This widget should be a SIMPLE BOOLEAN FLAG and that is it. That's what a single checkbox is for in EVERY other application...

This is very counter intuitive... Using pbarnetts solution in #3...
Core hax ftw.

With optionwidgets.module,v 1.69.2.27 2009/09/11, I have the code at line 290ff set to

  $element[$field_key] = array(
    '#type' => 'checkbox',
    '#title' => variable_get('sensible_onoff_widget', FALSE) ? t($field['widget']['label']) : isset($options[$on_value]) ? $options[$on_value] : '',
    '#description' => $element['#description'],
    '#required' => isset($element['#required']) ? $element['#required'] : $field['required'],
    '#default_value' => isset($element['#value'][$field_key][0]) ? $element['#value'][$field_key][0] == $on_value : FALSE,
    '#return_value' => $on_value,
  );

This way, if I don't set the variable I get the original behaviour.

Pete.

patch for 6.x
for 5.x - #4

Why again there is so big problem with implementing this in simple words? Too many explanations.

I need single checkbox with normal label, that's it.

Ok, I found:)
Solutions: #15 #45
http://stackoverflow.com/questions/102005/missing-label-on-drupal-5-cck-...

Solution: For single on/off checkboxes, drupal will use the on label specified in the allowed values field:

Type this into Allowed values list:

0
1|This is my label

Patch in #63 won't work as it will break any existing site using checkboxes. Marking back to by design rather than needs work because yched has made it obvious he/she has no plans to change this.

The same problem in 6.x, subscribe

You can do it through overriding checkbox, in your theme template.php

/**
 * Override theme_checkbox().
 *
 */
function phptemplate_checkbox($element) {
  $field_name = 'edit-field-fieldname-value';  // you need to change the value of this variable.
  if($element['#id'] == $field_name) {
    $new_title = $element['#title'] . ' <span class="form-required" title="This field is required.">(required).</span>';
    $element['#title'] = $new_title;
  }
  _form_set_class($element, array('form-checkbox'));
  $checkbox = '<input ';
  $checkbox .= 'type="checkbox" ';
  $checkbox .= 'name="'. $element['#name'] .'" ';
  $checkbox .= 'id="'. $element['#id'] .'" ' ;
  $checkbox .= 'value="'. $element['#return_value'] .'" ';
  $checkbox .= $element['#value'] ? ' checked="checked" ' : ' ';
  $checkbox .= drupal_attributes($element['#attributes']) .' />';

  if (!is_null($element['#title'])) {
    $checkbox = '<label class="option" for="'. $element['#id'] .'">'. $checkbox .' '. $element['#title'] .'</label>';
  }

  unset($element['#title']);
  return theme('form_element', $element, $checkbox);
}

Will you accept a patch that is backward-compatible and doesn't break existing sites ?

Oh, rather use theme_checkbox() override such as one posted above.

This is the very first time I had to use this type of field (though by now I wouldn't call myself Drupal newbie anymore) and I was/am just as puzzled by this behaviour as most people here.

After reading this thread I am even more puzzled by the reluctance to fix this. This display dilemma should be handled using the field display configuration tab.

I understand the programmer's reasoning but when most people don't or don't agree, why not seek a better solution? I will now use this field the way the developer intended it, although I don't think this is the most user friendly way as it is not at all consistent with the behaviour of other fields.

Just wanted to add my view to this discussion.

Nothing is certain but death, taxes and the counter-intuitive behaviour of CCK checkbox titles :-)

See http://drupal.org/node/115026#comment-503155 et seq.

Crap. I've just run into this issue. Using editablefields in a view. Have several checkbox items (onlist, instock). So now I have a nice table of my items, with a header label that says what the column is and with easy to checkoff status... except that every single entry repeats the "label" of the yes value over and over. Not only a waste of space, but very distracting from other information in the table. I can't change the "yes" value to a simple "Y", because it also is the only label that shows up for the checkbox in the standard edit form.

So I thought I'd just CSS the yes label to hidden. Nope. The format of the html surrounds the checkbox input like LABEL. I can't use display:none on the label without disappearing the checkbox too. After alot of wasted time still stuck.

@garyabbott You should be able to display:none on the 'label' and then override that with a display:inline on the 'label input'

@muhleder: Really? Pretty sure if you hide the container then all of the contents can't be shown no matter what you do to them.

Ahh, good point. You could try something like

label {
  left:-9999px;
  position:relative;
}


label input {
  left:9999px;
  position:relative;
}

See #3 and #42 above

I need this fixed as well. "Working as intended" is not an acceptable answer, IMO. I have been forced to hack the module code every single time I update to make this widget work like the other ones do. I actually need the "label" to BE the label on the form because my on/off text is completely different and not as descriptive or verbose (yes, there is good reason for it).

I was facing the same problem and came up with the following solution. No need to hack core or use themes. The idea is that the checkbox widget works as designed for the node form, but we change the label value when the node is displayed.

The allowed values for the boolean checkbox should look something like this:

0|Disagree
1|Agree

The helper function is:

function _replace_boolean_field_values(&$node, $true = 'Yes', $false = 'No') {
  foreach (get_object_vars($node) as $field_name => $var) {
    if (strpos($field_name, 'field_') !== 0) {
      continue; // Move on unless we are examining a cck field
    }
    $field = content_fields($field_name, $node->type); // Get the field metadata from cck
    if (!is_array($field)) {
      continue;
    }
    // Examine the field widget to determine if we have a boolean checkbox.
    // If so, then transform its value into something display-friendly.
    if ($field['widget']['type'] == 'optionwidgets_onoff') {
      $field_value = $node->$field_name;
      if (!empty($field_value[0]['value'])) {
        $node->content[$field_name]['field']['items'][0]['#item']['value'] = empty($field_value[0]['value']) ? $false : $true;
      }
    }
  }
}

You can then call this function from hook_nodeapi to transform the display value each time the node is viewed. The result would be a node form that displays a checkbox with an "Agree" label, and a node page that displays a field with the label "Agree" and the value "Yes" or "No".

If this works well then it can be put into a custom module dedicated to this task. Hope this helps.

Please just fix this.

The design is not good. Claiming that people are using as it is, is no reason to refrain from making changes. It needs to be consistent with the way other CCK fields work, that is, the 'Label' is the 'Label'. Also there needs to be consistency between the viewing and editing of the field.

Let me just state this again: The value label is not the field label.

OK, I think there is a mix up between the intended design for the 'labels' that go with the (on/off) values, and the 'label' that describes the cck field as a whole.

This other issue describes it better:
#572134: Checkbox text widget does not display label

I don't have a problem with how the on/off value labels are working, just the fact that the main field label doesn't show when editing a node, but does when viewing it.

@rkendall welcome to the plight;)

It would be nice to see this resolved, but it's been a little while now. FYI a couple of us have described, in detail, the exact issue you're having, so don't hold your breath.

I can't really see the default behaviour changing at this stage (we've been told it won't a few times). Having said that, I literally can't imagine how a site could exploit the 'feature' of two different labels depending on whether you're viewing or editing, but there you go. So that leaves the (I think pbarnett's) solution of writing a patch that gives you the option of sensible labelling, but which defaults to the old 'system'. Or make a contrib widget...

CCK checkbox widgets - confusing users since February '07 ;-)

Pete.

Arrgh, inconsistant behavior! The Edit and View shows different things! Please fix!

Yes, +subscribe

Can't we just start a protest or something... :P

I sincerely believe that what happens here goes against everything that has brought Drupal the success it has now.

I'm very thankful for this wonderful, wonderful module and I respect every second that the maintainer has put into the module but open source is also about respect for the community's input and that is sorely lacking here tbh. :(

We should get Dries involved. :P

Again: Please, read comments #12 through #16. Then read comments #53 through #55.

See #65 to read on how to use this widget.

The problem: this counterintuitive for those that do not understand how this widget works internally.
The cause: it is the checkbox element provided by Drupal core itself that works different than other form elements.

So, what to do?
1) Changing the behavior of the single on/off widget in CCK will break other sites that are using it today: unacceptable. Because this reason, this issue is maked "by design".
2) Users need to learn how to use the single on/off widget as implemented in CCK.
3) Those that do not like the behavior of the single on/off widget in CCK, or need something different should find another solution. For example, try overriding the theme function as suggested in #69. Another approach: write a separate contrib module that works with the checkbox element in Drupal the way you exactly wish. This will cover all your needs, and it will be 100% compatible with existing installations of CCK.

What about #85?

Edit and View should be same. Would like to use #15...

@bkraegelin: That was answered in #16.

Wow, did you just confirm exactly my point in a spectacular way! :P Out of this entire discussion you point to the 8 comments that confirm your point of view (as half of them are yours), ignoring the 80 other comments from various users saying that its behaviour is counter intuitive!

Don't get me wrong, I'm not attacking you or your work and yes, I understand exactly why the module works like it does... (just because I don't agree doesn't mean I don't understand) but that doesn't mean the cries of agony voiced here are unjustified! I also understand that changing how this works now is not an option, considering the backward compatibility issue. However, I (together with many others by the look of it) do ask that you will at least consider a strategy to move toward a solution that at some point in the future will make this widget's behaviour consistent with other CCK widgets/fields. It will be a lot easier for people to accept the current behaviour if we know it will change (after all, we're all encouraged to improve Drupal by voicing our concerns and opinions).

I personally believe that contrib modules to override/repair something which is in core (or will be shortly) are Bad Things.

oh well, I tried.

I have no particular interest in doing one thing or another. Even when it may seem the contrary, I'm just trying to share my particular point of view thinking it may help someone, to save time or whatever.

Sometimes, the best solution is not possible because a myriad of reasons. Maybe it's not the right time, maybe it's not the right place. If you're worried about the future of this kind of widgets, then you should look at Drupal 7, or maybe Drupal 8, which is where new stuff for Drupal core is being discussed now.

In case it has not been mentioned yet, here's another possible approach: Use an "Integer" field with a "Check boxes/radio buttons" widget configured to allow multiple values (so that the form element becomes a checkboxes element) and one single option in the "Allowed values" list that looks something like "1|On".

#841266: Missing label for boolean fields when adding content is the issue for fixing this in D7 - patches welcome...

Thanks guys, good to see this will become a thing of the past in D7. :)

ahem... It won't happen if all people do is subscribe to the other issue...

+1 for using label as the label. Otherwise all the more reason for people to point to drupal as not being user friendly.

Looks like there's some great progress now! :)

Heh, at least in D7! But yeah, I'm happy to see it. I guess we managed to accomplish something after all with our incessant complaining! Democracy works X-D

Yup; only took three and a half years, too :-)

Wow, there's a lot of whiners on this thread. How about following the advice of the developers, and using the field in the way it was intended by them [I did]? Your other option is to create a custom solution for yourself!

This works for me in drupal 6.19

|
1 | Tekst to put next to checkbox(titel)

Ex. #34
|
1 | Requires MacGuffin

If not check there is no display of the field

@chowdah (#100), maybe we should repeat what that advice was:

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.

Though that should have been mentioned in the help text on the field's config form somewhere ;-)

@#100
Because our paying clients want a true "on/off" check box and are not interested in my reasons why they need a "Yes, I want this option selected/No, this option was not selected" check box instead. The ability to switch back and forth between check boxes and ratio buttons is not an exiting enough feature to cause them to change their minds. :-)

Seriously, their is a very basic use case:
Yes/no check box that does not show "yes" as the label on the edit page, but does show "yes" or "no" on the node view page. This cannot be done with cck as it is.
I have had to make a custom module for my clients that is just a fork of optionwidgets.module with one line of code changed. The problem is that if there is ever a security fix for that module, my clients will not get it.
I would strongly recommend that we allow the d7 patch mentioned above to be back ported to d6 cck as it does not change default behavior. Forking and creating duplicate modules are counterproductive in open source projects.

Different workaround I haven't seen explicitly stated, just mentioned as a tangent...

Install http://drupal.org/project/editablefields

If you then set your checkbox fields to editable in the node, the node will display the edit widget, which is... a checkbox. Only works if you have permission of course but might be a help for quite a lot of use-cases. In our case user can either see AND edit something, or can't see it at all, so it works for us.

@malc0mn: True dat!

I think this is quite absurd from an usability point of view. Yes, there are workarounds, No, it makes no sense. If there is a label field, this label field should be used and displayed. Without using the "1|This will be the label" workaround the on/off switch looks unprofessional and easy to miss on an edit page.

I didn't read all the thread, but seems there is a conflict between the developer and the community, and that makes no sense at all. Please FIX.

separate tags

subscribing

Hi have written a patch for version 6.x-3.x-dev that should hopefully do the following:

1. Not break backwards compatibility
2. Adds a switch to each field instance to allow the default behaviour to be turned off
3. If default behaviour is switched off then the following will happen
   • The actual field label will be used for the field label rather than the ON value
   • This behaviour will only occur for this particular field.

Please test and let me know if you have any problems.

gamelodge, thank you so much for the patch! It works great and didn't mess with other instances that I had already hacked individually.

Excellent patch, gamelodge! Thanks!

I should have written one ages ago, but you know how it is...

subscribing

Another (lazy) solution is to add a #prefix to the widget :
Around line 291, when the element is built add this :
'#prefix' => '<b>'.t($field['widget']['label']).':</b>',
Which should give you :

$element[$field_key] = array(
    '#type' => 'checkbox',
    '#prefix' => '<b>'.t($field['widget']['label']).' :</b>',
    '#title' => isset($options[$on_value]) ? $options[$on_value] : '',
    '#description' => $element['#description'],
    '#required' => isset($element['#required']) ? $element['#required'] : $field['required'],
    '#default_value' => isset($element['#value'][$field_key][0]) ? $element['#value'][$field_key][0] == $on_value : FALSE,
    '#return_value' => $on_value,
  );

Hi,
I see this issue again on the Drupal 7.
Any way to fix this without hacking core.

Thanks.

Just set "Use label instead of value for 'on' as label" , because this only appears when no 'on'-value is set.
Fixed for me.

With me, on Drupal 7 the option "Use field label instead of the "On value" as label" doesn't work

It does for me.

#115 works for me too on drupal 7-4.3