Saving Empty Radio Button Values in WordPress

One of the projects I’ve been working on recently presents the user with a comprehensive set of options. As usual, the options take the form of a variety of different elements:

  • input text fields,
  • radio buttons,
  • select elements,
  • and more.

In most cases, you should be familiar with initializing default values for all of these element types. Radio buttons may be the exception. And if they are, then you’ve no doubt run into a PHP notice when saving empty radio button values.

And having PHP notices is no good, right?

Regardless of if you’re using the WordPress Settings API or some custom serialization code, these notices can still show up. If you use Query Monitor, then you’ve likely seen this show up in your menu. Similarly, if you use the Console (or another application) to monitor your PHP logs, you’ve probably seen the error as well.

OS X Console

One place in which this can be tricky to deal with is when you’re working with radio buttons without an initial value.

Saving Empty Radio Button Values

That is, a user may be presented with a screen but may not select an option during the time they’re on it. Thus, they are left saving empty radio button values.

When the page reloads, and you’re trying to retrieve the value of the radio button from the array of options (or however you’ve opted to store it), you’re going to get a warning because the index of that particular value will not exist.

And though some may argue this is too strict, I’m no fan of shipping production-level code that generates any warnings. Assuming that you don’t want to initialize the group of button buttons with a default value, what’s the resolution to this problem?

First, it’s not terribly uncommon to see code that checks to see if the value is set and then, if if’s not, will provide a default value. This is something that can work, but it makes the code a bit weird to understand. That is, you’re taking the collection of options, checking for the presence of the value, and then setting a value after you’ve already retrieved it.

I’d rather work in the other direction.

That is, I’d like to have a value that’s set and then when the user clicks save, I want to save the default value. This way, I don’t have to do any condition checking to mess with the collection of options just to make sure I’m silencing a PHP warning. Here’s one approach I’ve found useful:

  1. Create your radio button (or your radio button group) and make sure that it has a unique name. If it’s a group, then it will likely have a name in the form of acme[key]. If none of the radio buttons have a default value, then create a hidden input text element with the same name and give it an empty value.
  2. When the $_POST collection is set, the hidden input text value will be used in place of the radio button. If on the other hand, a radio button value is select, that value will be utilized instead.

The code will look something like this:

Note that it might be worth documenting why you have a hidden input element in the markup of your page, but the purpose of the code won’t change. During the serialization procedure, the value will exist in the $_POST collection; you can sanitize it, write it to the database, then safely retrieve it.

This will prevent any future PHP notices from appearing because there will be a value associated with the option. Even though it’s empty, it’s still the presence of the value. Furthermore, you’re not left with having to fake a value when the page loads.

Other Ways To Do This

Finally, this is not the de-facto way of doing this. For example, you could create code that initializes empty values for all of your options; you could set a conditional that looks to see if something is present for each key (though you’d need a list for every key that could potentially exist), and so on.

Each variation has its advantages and disadvantages. For radio buttons, this particular approach is one that I’ve found to be useful more often than not.

3 Replies to “Saving Empty Radio Button Values in WordPress”

  1. You are demonstrating generating a settings page and not forcing a radio button to be selected. I must ask, what will the code that uses the settings do when no radio button was selected? Surely it will have a default, and therefore this default should be the default radio button in the settings page.

    Make sense?

    1. Yes, it makes sense but there are times in which a settings page will be asking a user to select a set of default values on their own.

      In the context of something like themes, there should always be a default value. But if you’re working on a plugin for a commercial product and the user is basically driving a set of configuration options that will dictate how future behavior will work, we can’t anticipate what’s best for their use case (and this is coming from the state of the current project).

      Perhaps a more succinct way of putting it is this: If there are design-related tasks at hand, then yes, absolutely there should be defaults. But if you’re working on whether or not something like a file from a third-party should be imported via an API call, there’s no way to anticipate if they should want this or not.

      This is essentially providing a GUI to a configuration file that can be later read and parsed.

      I hope this makes sense. If not, I’m happy to clarify further!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.