I'm using the Joomla radio button form field type and am having trouble with option values that are strings. I'm not sure if I'm doing something wrong or if there is a bug there.

So in my component form xml I have a field like...

    label="label text" 
    description="description text" 
    hint="hint text">
  <option value="public">Public</option>
  <option value="registered">Registered</option>

But when I create a new item with the form that uses this, the default is not set correctly. Then when I save the item the "myfield" value is "1". This just seems to be a problem with the setting of the default really. If I select one of the options and save, then the string, for example "public", is saved. Then if I edit the item again it displays as "public".

So, as a quick breakdown...

  • It saves the radio value string if it's set
  • It loads a saved radio value string
  • It does not pre-populate the default radio string on new items

I had a look at the layout file in "layouts/joomla/form/field/radio.php" and could see the default value coming through as 1, "public" as it should have been.

The field docs are good, but didn't really give specifics on if value had to be a number, however in the three examples on the doc it is https://docs.joomla.org/Radio_form_field_type

This is in a custom component on Joomla! 3.7.0.

1 Answer 1


I tested your code and it works for me in a component. The values do not have to be numbers.

My best guess would be that it's something to do with your database field type. If it's saving as 1 instead of "public", are you sure that the "myfield" field has not been set as a boolean or integer instead of allowing for a text entry of at least 10 characters?

  • Hi Richard, thanks for the reply. In your test was the default option selected when you created a new item? May 16, 2017 at 17:43
  • Yep, the default value is selected. The only thing I changed in your code was the title of "myfield" so that it would work with the database structure of the component I tested it on.
    – RichardB
    May 16, 2017 at 18:15
  • Thanks Richard, yea, seemed like it was an odd bug in my model, and another parameter conflicting with the field name. May 17, 2017 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.