ACF Pro v5.2.7
When creating radio button option fields for the “Add/Edit User” form, the first option is always checked despite entering nothing in the “Default Value” setting.
By default, radio buttons assume that one of the options is required. This is the way that browsers work. If you want to have a no value option then you need to create a option that represents no selection. I usually use “none”.
There is no reason that one radio button from a set has to be pre-selected. Mozilla’s section on the
<input> element says nothing to that effect (https://developer.mozilla.org/en/docs/Web/HTML/Element/Input).
ACF has a “Required” setting for radio fields, which is completely redundant if one of them is always pre-selected.
ACF also has a setting for radio fields called “Default Value”, with the description “Appears when creating a new post”. If there is nothing entered there, it follows that nothing should be set as the default.
All this would be academic, but the functionality I am describing has a particular (and important) use: A set of radio buttons with none pre-selected is a well-established way to ensure that users have to make a decision about relevant question/setting/etc. In other words, they are a way to get the form to generate an error if the user hasn’t selected one of the options. This is not possible if one of the radio inputs is always pre-selected.
I will flag this topic for the developer. I can’t say why it works the way it does, and the thing about required becoming non-useful, it’s something I have found myself asking, it’s a radio button, of course it’s required.
Thanks @hube2 – I wasn’t aware that topics needed to be flagged. Does Elliot not read the Bug Reports forum?
Regarding your statement “it’s a radio button, of course it’s required”, I think we’re kind of talking at cross-purposes. You’re talking about the code needing one of the options to be checked in order to provide information. I’m talking about the user being required to take an action.
Say I have a form that asks for the user’s age range. The options are “Under 21” or “21+”. In order to answer the question, of course, one of these is required – but maybe I don’t care if the user answers the question; or maybe I do. But one of the radio inputs being required in order to answer the question is a different issue from the question be required to have an answer.
If the form always has “Under 21” checked when the form loads, how do I know if the user just didn’t bother changing it? Or passed over it by accident? I know you suggested that I should have a third option “Rather not say” that would be the default – but what if the information is mandatory?
You could make the argument that a
<select> element could be used, but
selects are meant for combining mid- to large- size groups of options in a compact display. When you only have 2 options (or only a small number), radio inputs are clearer and easier to use. For mandatory questions with binary options they are the exact right solution.
I understand what you’re talking about. As far as flagging the topic, the Developer does not spend his time reading all of the topics here. If he did he’d never have time to work on ACF. There are some of us here that do our best to answer questions and make sure that a bug is actually a bug. When I’m pretty sure its a bug I can and assign the topic to the developer add a note, that way the next time he’s here he knows which topics need his attention.
Squarestarmedia, I have the same problem. The solution would be:
1) Radio Button
2) Tick required
3) Fill in options
4) Default value: null
This would have a null value in the field, neither radio buttons will be checked and the form won’t validate unless the user selects one of the radio buttons.
I found it elsewhere in this forums, I didn’t come up with it. This is not a definite fix and I believe this bug should be adressed (if no default option is given, radio buttons should remain unchecked!)
I posted a message on the dev repo about this topic.
Thanks for the conversation, it’s great to get some different perspectives on the radio field.
It sounds like there is a good case for the radio field to allow a ‘no value’ selected.
I’ll admit, my interpretation of a radio field is that it always contains a selection and that is it’s purpose, however, that is just my interpretation.
My first thought is to add a new setting to the radio field called ‘Allow Null’ – similar to the select field settings. This would allow the radio field to load without any value.
But maybe it makes more sense of all radio fields to ‘Allow Null’ by default, and the user should set a default value if they wish for a value to be selected.
This is a good discussion, and one I might put out on twitter to get some more perspectives on.
My take on it is based on a few things:
<input>element, linked in my second post above, supports this idea)
I’d love to see an unchecked-by-default radio field in ACF, as I’ve had a few scenarios where it would have been the perfect solution.
Given the perception that one member of a radio group is always selected (expressed by a number of people on this issue), maybe it would be more immediately obvious for admins if there was an “allow null” option.
That said, because the current interface already allows a default item to be set, my feeling is that it would be more intuitive for no option to be pre-selected unless it is specified in the Default Value area.
I’ve just had a thought.
If I were to leave the default behavior as is and add in a new setting called ‘Allow Null’, this would do a few goods for the plugin:
1. Avoid issues with existing radio fields (a developer may have written code expecting the radio field to always contain a value)
2. Provides an opportunity to add in some JS that would allow the user to deselect a radio field option. Therefore ‘Allowing Null’ which makes sense.
3. Obviously allow new posts to load with no radio field selected solving the original issue.
That sounds good. After writing my last post it occurred to me that changing the functioning to be unselected by default could cause problems for existing sites. Adding the “allow null” option would be the better course, unless it is possible to only make the change for fields that are created after the update.
I’m not clear on what you mean in point 2. Do you mean that you would add that functionality into the radio field as an option? That would be great – it would mean that if a person accidentally clicked a radio option that wasn’t required, they could uncheck it again, which is often not possible in forms and can be really annoying.
Yes, The new allow_null setting would allow a user to unselect a radio field input. This is normally not allowed by a browser and is the main reason why a few other developers are saying a radio field should not allow null (because you can’t unselect a value).
I’m happy to add in this new setting, it makes sense from all angles!
I’ve just come up against this exact train of logic where I wanted to give the user a Yes/No option, but wanted to definitively confirm that they are actually clicking the button as opposed to skipping over it.
I was initially concerned that allow_null would allow the field to submit as Null even if I also set it to required as it wasn’t clear from this thread, but just tried it out and found that this is not the case, which is brill.
Radio loads in as empty, until clicked, at which point it will verify, the fact that it allows you to deselect it actually is somewhat arbitrary as you still can’t submit the changes at that point. Unless you changed the script to have the allow_null option turn off once a selection has been made?
Either way, I just wanted to +1 this solution as a good one.
Ok, just commented on another thread about this which mentioned the allow null option, but wasn’t aware this was added after the fact to address this. so that is good.
Still is a little confusing how it sets a default value when you don’t input a default; but at least there is a solution to this now 🙂
You must be logged in to reply to this topic.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
Reason I love @wp_acf n°283: UI is seemless. It's like it's part of WP core.— hwk (@hwkfr) November 29, 2019
Plugin devs, here's a secret:
Nobody open your admin page & say "Oh god, I love the feeling of being outside of WP. And this new out-of-context colors... It's genius!"
Great UI is seemless UI
© 2019 Advanced Custom Fields. Subscribe