Create Documentation about removing N/A option for not required radio buttons

Sorry, but won't happen. Removing the n/a option means you cannot empty the field. 'no value' is a valid value for a non required field.
If the 'n/a' text bugs you, it can be overriden in the theme.

The understandable need of having an "empty field state" for non-required fields should be accommodated by :

- displaying only the "allowed values" (without any N/A option)
- disallowing the possibility to specify another default value

In this way the empty field is the default compulsory state for non-required fields - no undesirable N/A option is displayed, while this state is in fact valid by default. This applies for radio buttons. For a drop down list for non-required fields the default empty value should be something like "please select a value" and no possibility of specifying another default value.

This is a more sensible approach than forcing the display of a compulsory visible N/A option for radio buttons, or a stupid blank space for drop-downs.

jdwfly asked for previous report -- http://drupal.org/node/299490 is one.

I found this because I came looking for a solution to the unwanted N/A radio button I got.

I have run into jdwfly's use cases a number of times. It doesn't make sense to me that there is no way to not show N/A when it it not intended to be an option for the user. Making the field required has no effect, in CCK 6.x-2.4 anyway.

Sorry, disregard my last comment -- setting the field to required does work. Switching version back to OP's original value.

I confirm markj comment. It's fixed in the current version by making the field mandatory. Makes sense.

I know what you mean. When I took my principle user through our node edit form, she asked me to explain why the drop-downs were marked as required. When I told her that we needed to make them required to eliminate the 'N/A' option she was confused. After I told her we had no other simple way of eliminating that option we moved on, but it did require a bit of negotiation.

@jdwfly: There's no way to empty a single select list. So, the same behavior is implemented for radios. This is a design decission because CCK wants to offer a method to empty this kind of fields when they are not required. Nothing stops you from creating an alternative radios widget, or implement hook_form_alter() to remove the n/a if you don't want it. It's been said this won't happen in CCK, and I think you cannot force maintainers do what you want. This is implemented for a reason, and you may or may not agree, but you have the option to choose what it is, or do it yourself the way you wish.

A drop down is a component that offers the users with a set of values to choose from. Same with radios.
If you do not want to force the user to select an option, then what you want to do is provide a N/A default choice. Otherwise, it is mandatory to choose one of the other options.

I.E.
-What is your gender: Male / Female (should be mandatory and therefore no n/a option)
-Do you love your kids: Yes / No / N/A (It is not mandatory to love your kids because you may not have any, then you select N/A)

I wonder why this nonsense "N/A" was to be a part the radio field and it is not even removable on my version of Drupal even if I make the value required.

Now I have to use a Single On/Off check box to do the required job, that works for me.

And when I use Single "On/Off" check box, the field title name is not displayed on content pages. Only the check box is displayed.

Please, read #3 and #13.

Nothing stops you from coding another radios widget for CCK in contrib. If you wish this to be documented, nothing stops you from adding a page to the CCK handbook to describe how the n/a option could be removed.

I just wanted to weigh in on this for the record... I agree that we should have bullets without the N/A requirement in non-required fields.

I very frequently encounter the issue of not wanting to have an N/A option but do not want to make the field a required element. An example is on a survey form, where I do not want to force folks to reply to every item, yet having to list the N/A in these examples is very intrusive.

I appreciate markus_petrux response and will do what I can to contribute, but this is an issue.

Thanks to all.

Yes, I agree too. I think this is an issue. Please fix it.

Hm. So I tried to remove this with hook_form_alter(). However, #options is nowhere to be found:

array
  '#type' => string 'optionwidgets_buttons' (length=21)
  '#default_value' => 
    array
      0 => 
        array
          'value' => string '' (length=0)
  '#required' => string '0' (length=1)
  '#columns' => 
    array
      0 => string 'value' (length=5)
  '#title' => string 'Choice' (length=6)
  '#description' => string '' (length=0)
  '#delta' => int 0
  '#field_name' => string 'field_choice' (length=12)
  '#type_name' => string 'article' (length=7)
  '#tree' => boolean true
  '#weight' => string '32' (length=2)
  '#access' => boolean true
  '#count' => int 9

This seems to be because these are added in the form element's #process step by optionwidgets_buttons_process().

I tried for awhile to add my own #process function at the end, but since the element's not initialized yet, it gets blown away by optionwidgets_elements().

So then I turned to an #after_build function on the element instead. It initially appeared that this also didn't give me #options, but I eventually found them buried inside of a 'value' sub-index. But, it turns out that was a red-herring, since unsetting $element['value']['#options'][''] didn't remove the choice from the widget display.

Just as I was about to give up, I noticed that the N/A, Yes, and No choices were repeated once again in the top-level $element array. Unsetting $element[''] in my #after_build function finally removed the option from view. Huzzah!!!

This was not even remotely pleasant to figure out, so I documented this at http://drupal.org/node/617694. So technically, this issue is now fixed.

But, a question to yched and other CCK maintainers: does it make sense to add a toggle for this on the widget settings form? It seems like a popular enough request. I understand why it's the way that it is (since without it, once you make a "Yes" or "No" choice, there's no going back to "Wait, I didn't meant to answer that...") but I don't think this is something that most people could've figured out on their own, and it would probably lighten your support request load.

Heh. So after I twittered about my frustrations on this issue, chx piped up and noted that #after_build is a big hack (and probably why I had such issues with this) and suggested a better approach: using hook_elements() to extend the 'optionwidgets_buttons' type. So I've updated http://drupal.org/node/617694 accordingly. This is nice, because now it'll just do it everywhere without any performance overhead.

Still seems like an option to turn this on/off per-field would be helpful, though.

Best practice is that radio buttons always have a default selected state specified per W3C recommendation and RFC1866. Not initially choosing an "on" element is handled differently in different browsers (the behavior is "undefined", as the W3C says) -- I seem to remember Safari automatically selecting the first option and Firefox not, but I could be mistaken.

http://www.w3.org/TR/html401/interact/forms.html#h-17.2.1
http://www.ietf.org/rfc/rfc1866.txt

Another usability issue is that once the user chooses a radio, they cannot unchoose it as they would be able to do with a N/A-type default. I would use a dropdown box instead of radio buttons if there should be no default.

I considered opening another ticket titled "Radio fields should always be required," but this seems as good as any place to put this comment I guess.

I created #621366: Enforce comformance to W3C recommendations on radio buttons? as a follow-up to fix #24 in core (though not until D8 given the point in the cycle we're in). Thanks! I learned something new.

However, if you want to change the behaviour of radio buttons in CCK to make them always required, then yes, that should be a separate issue. This one is just about documenting how to remove the extra option. But feel free to cross-post it here once you create it, since hopefully all interested parties will see it.

However, if you want to change the behaviour of radio buttons in CCK to make them always required, then yes, that should be a separate issue.

In fact, this issue started in that direction.

I do not plan to spend time on this right now, however. So, unless yched and/or KarenS have the time soon, I think it's fine to say the future of this issue depends on what happens with #621366: Enforce comformance to W3C recommendations on radio buttons?.

I would like to add that if someone wants to change this behavior in CCK for their site, it is possible using hook_form_alter() + after_build callback. Here you can change the items in the radios element at will.

@markus_petrux
@#27 you said:

I would like to add that if someone wants to change this behavior in CCK for their site, it is possible using hook_form_alter() + after_build callback. Here you can change the items in the radios element at will.

I would like to be able to do this (Please see http://drupal.org/node/648110), but i'm totally confused how to go about it after reading documentation at drupal.org. Could you possibly point me to a few resources on drupal.org or elsewhere that could help to clarify?

Thanks,
Tom

I want to throw my two cents in... when it comes to usability for the end user... this should be a consideration for the programmer.

CCK is the CONTENT CREATION KIT... this is for DEVELOPERS to use. The whole attraction of Drupal for developers is its flexibility. We are given the power to make end user decisions and use Drupal as a tool for realizing these choices.

CCK adding N/A without asking is like Black and Decker forcing all drills to make a certain size hole because "studies have shown this is a best case scenario"... however, it is not every scenario. The tool should help the person using the tool and not attempt to be all things for the recipient of services that the tool was used to deliver.

I wish there was a different status so this could be marked "Refuse to fix out of typical nerd pridefulness instead of humbly admitting that simple may, in fact, be better for this feature". I suggest an acronym: RTFOOTNPIOHATSMIFBBFTF

By the way, this acronym is not changeable because I created it and I believe people may be too confused to use it competently if they alter it.

</rant>

By the way... here's a handy way to remove this abomination using a preprocess function...

Before you assign your radios to a variable use the following code:

  unset($vars['form']['group_if_in_fieldset']['field_the_radios']['value']['']); //remove the pesky CCK N/A radio

I actually did add it to the book pages linked... I should probably give some more information for those that are not familiar with the preprocess procedure. Thanks for making the original post... it led me to an appropriate solution. :)

Thank you, your idea really helped me

This feature sucks and it is plain stupid. And what the heck does "N/A" mean? Not applicable? In gui applications i do not see this "feature". And why all the hoops to disable it?

I find this fascinating--the programmers claim, because it must be there, we will show it to the end user, but NOT make them choose it, because it has to be there...really?

If it HAS to be there, yet the end user does not HAVE to choose it then cant we put it there ourselves, whatever it is they do not HAVE to choose? Rather than show them something to confuse them, which they do not have to select?

It's like you're claiming if the user chooses nothing then we must insert X in the field. Then do it! The user has no need to see the X, which they don't need to pick, that you plan or need to insert into the field....can we get a new module that inserts this called--Just DO IT!

I completely agree with you. I still do not understand why this decision was made. They carried this over into Drupal 7, as well.

Totally agree. I was actually going crazy about the stupid N/D (yes N/D since my Drupal is in spanish, which made it even more absurd).
Not being mandatory means "that can be empty". Being empty is just that!!. Not being in a "N/A" state. Ok, from a programmer´s stand it´s "N/A", but it´s just plain confusing and absurd to show that to a N/P (non-programmer ..).
Thanks to webchick for this little and very simple snippet that I would love to make Core. N/A nevermore!!

If I didn't know any better I'd think the U.S. Government was behind creating this "solution"

Wow! The rigidity in even acknowledging this behavior is not what most people would expect have the feeling of dogma. It is a shame. Technically-oriented people ought to be more open minded that their solution to an issue may possibly be improved upon. Adding a checkbox in field setting to control this phantom N/A makes plenty of sense, and you can leave the default behavior as is,

I am new to Drupal (though not to web apps and CMS), so I am being careful not to step on toes. I am extremely impressed with the power and flexibility. I found all the coding solutions and they work, but they are really just workarounds, Radio buttons is basic functionality, and a system like Drupal ought not expect its users to code for basic functions. I have used at least a dozen web application frameworks and content management systems, Simply GUI elements like radio buttons just work. Coding is usually expected for advanced workflows and behavior, not for making radio button show what you expected to show.

.