When you create a CCK text field using the checkbox on/off widget, the assigned label does not get displayed in the form but does get displayed in the node. Help text is properly displayed.

It's independent of whether the label is above or inline, box checked or not, and is independent of the theme.

Comments

markus_petrux’s picture

Status: Active » Closed (works as designed)

This is by design. The on/off widget uses a single checkbox element, and FAPI only renders the label for the checkbox value. You have a lot of examples f this behavior, for example the "Required" checkbox in field settings.

As an alternative, you can use the checkboxes widget with just one allowed value.

druplicate’s picture

I'm not speaking of the label for checked VS unchecked, such as yes/no, or on/off, as appears in the allowed values list.

I mean the custom field label in the CCK "basic settings" setup page, like for example "Featured item". Without this label, no one would know what the check box is for.

hubkei’s picture

subscribing - (Allowed values are showing properly), but same issue here: checkboxes do not show "Label:" = Header of the field.

apemantus’s picture

subscribing. Same as above. The workout is indeed to use the Checkbox/Radio widget with the number of values > 1 but only a single allowed value, which this seems a bit clunky.

jon_stewart’s picture

Priority: Normal » Critical
Status: Closed (works as designed) » Active

Subscribing - how do you fix this to behave the way we want it to?

Ogredude’s picture

Subscribing - Same issue here.

Anonymous’s picture

Subscribing - same issue here

djipp11’s picture

+ 1 subscribing

dagomar’s picture

how can this be by design? Ludicrous!

rkendall’s picture

This still needs fixing.

There is another issue similar, but I think this one describes the problem better
#115026: Labels for single on/off checkbox field aren't appearing

I think the reason these issues are still around is because:
- the field label doesn't display as it should
- some users are confused about how the value labels work (ie, only the 'on' value displays), which is by design.
- the maintainers are confusing the first issue with the second.

AndyF’s picture

subscribe

nodecode’s picture

Version: 6.x-2.5 » 6.x-2.7

Yeah what's up with this missing field label? The bug is still present in 6.x-2.7 and I bet it's in 2.8 as well considering there is no evidence of a fix yet. This issue has been around for almost one year. Anybody resolve this on their own?

@maintainers: Where in the module code does the the 'off' value get left out of the form for a single-value on/off check box? It looks like the Field Label is also being left out at this point.

kenorb’s picture

mikedotexe’s picture

Yeah, I'm pretty new to Drupal, but looking at the link from #10 I've got a basic fix that works.

Before, it was displaying:

[checkbox] Yes

I changed the code in modules/cck/modules/optionwidgets/optionwidgets.module

on line 292 from:

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

to:

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

Now at least this single checkbox appears as:

[checkbox] Appear on front page

So the label is appearing instead, so you know what you're checking.

(I'm running Option Widgets 6.x-2.9)

coakeson’s picture

If you read the instructions for completing the configuration form of a single on/off checkbox, you wouldn't be having these troubles. It says very clearly in the Allowed Values text area, "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."

nodecode’s picture

@mister-h13: Read the full thread (particularly #10). The problem is not the value label that's missing, it's the field label that's not showing.

matkeane’s picture

+1 to implementing a fix for this.

I wanted to just quickly add a group with 8 checkboxes corresponding to the languages in which a video will be translated. In my mind I had 8 checkboxes, with a label with each language and then a checkbox to tick if the corresponding translation is done. What I end up with is 8 checkboxes, all marked 'OK' which, as previous posters have pointed out, is the value-label, not the field-label. So now I've changed all the value-labels to get the result I want, but it feels like more of a workaround than a solution. Surely, if the user has gone to the trouble of entering text in the 'label' field (a required field, by the way), it would be polite to show it on the form?

What's more, the official solution leads to more confusion on the node page, where both the field-label and the value-label are shown. Since I had to change the value-label to be identical to the field-label, in order to get the display I wanted on the form, the display on the node page makes no sense - rather than 'En: OK', I get 'En: En', and the same applies on Views results pages. I realise that there are ways around this - by diving into the Forms API, or the theme layer, but it would be nice if there was a straightforward solution using the UI.

Having searched for a solution, there seem to be several issues about this, which have been closed out as 'User is doing it wrong', but this feels like a UX bug.

Onfire60’s picture

This is completely a UX bug. I'll give you a small example of something I'm dealing with right now. I have a single on off check box the field label is "Don't Email" and the on and off values are "Don't Email" / "Uncheck To Recieve Email" witch totally makes sense from a users experience on the node. But lets say I wanted to filter on this field in a view and my select box has these two options in it "Don't Email" and "Uncheck To Recieve Email". Witch of these makes sense to the user that is filtering the view of witch is checked and unchecked?

To make this a simple fix make the field use its field label on the node form. Then i could set the options to
0|Yes
1|No

And when i add the filter to view it will give me clear cut options of "Yes" or "No".

This is just one specific example of an issue with this scenario. But I am willing to bet there are a lot more people that find this annoying and confusing to use at times. Just Sayin.

EDIT: #14 Posted by mikedotexe actually temporarily fixes this issue but there needs to be an option to turn off the use of the static field label. Then we can all be happy campers...

gamelodge’s picture

kenorb’s picture

Priority: Critical » Minor
Issue summary: View changes