This post is part of a series on Sanitization with the WordPress Settings API. Here is Part 3.

In continuing to work on sanitizing arrays of input with the WordPress Settings API, there are two things that we need to do:

  1. Refactor the existing code that we have so it’s as clean as possible
  2. Determine what fields we’re going to use to mark as required

In this particular article, we’re going to focus on both. This particular article is going to include the code necessary to tighten up our existing code and then we’ll begin laying the ground work for introducing a new class – a validation class – when we begin looking at the second step.

Inputs From The WordPress Settings API

Ultimately, we’re working our way to setting up what fields are required and what their corresponding error messages should be – but we’ll get to that starting in the next article.

For now, let’s focus on tightening up the code that we currently have (with the help of some of the comments over the past few posts) and then determine what fields we want to mark as required.

Refactoring Existing Code

In the last article featuring code, we left our sanitize function looking like this:

And that works, but as one commenter pointed out, it’s a bit redundant:

To be honest, I’m not super sure what you’re trying to do here but in any case, the isset check is redundant. You’re iterating over the keys of the $input array, so the current index is always set.

The thing is, whenever you submit a collection of input fields via the $_POST array in PHP, they are going to have a value even if the value is an empty string. Looking to see if an empty string exists is part of what we’ll be doing in the next step of this article.

For now, let’s clean up some of the code that we currently have. Namely, let’s remove some of the redundancy that we have in checking to see if a value is set or not.

At this point, we’ve got the code as lean and as functional as it can be given it’s current state. Of course, we’ll be adding more to this over the next few articles, but first we need to identify what we want the user to be required to enter.

Setting Required Fields

Given the work that we’ve done this far, WordPress should be saving data to the database. Eventually, we’re going to look at retrieving the information from the database, but only after we’ve marked certain fields as required.

So let’s do that now. Given the following screen shot that we’ve been using:

An Example Settings Page

An Example Settings Page

What fields should be required? For the purposes of this series of articles, I’m going to chose:

  • Address 1
  • City
  • Postal Code

But you can feel free to choose whatever you want as the strategies that we’ll be employing through the use of the validation class that we’re going to introduce is going to make it easy to handle each field on its own.

And that’s where we’re headed next.

Series Posts

  1. Sanitizing Multiple Values with the WordPress Settings API
  2. Sanitizing Arrays: The WordPress Settings API
  3. On Pause: The WordPress Settings API
  4. Refactoring Input Sanitization with The WordPress Settings API
  5. Validating Input via the WordPress Settings API
  6. Validation and Sanitization in the WordPress Settings API