This post is part of a series on Sanitization with the WordPress Settings API. Here is Part 4.
Up to this point, everything we’ve talked about regarding the WordPress Settings API and saving data to the database has been based around two ideas:
- We need to sanitize the input
- We haven’t been concerned with any particular fields being required
At this point though, we’re ready to start talking about how to tackle this particular issue. Since we’re already familiar with how to sanitize the data, we’re going to build off of the code that we already have.
An Example Settings Page
That is, we’re going to look at how to validate the following fields:
- Address 1
- Postal Code
Furthermore, we’re going to see how to tackle this from an object-oriented approach, we’re going to look at what’s needed in order to add an error message if the required input is invalid, and we’re also going to look at how to prevent saving information to the database if it’s empty or invalid.
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:
- Refactor the existing code that we have so it’s as clean as possible
- 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.
This post is part of a series on Sanitization with the WordPress Settings API. Here is Part 2.
Whenever we’re in the process of teaching a new idea to someone – be it if you’re a teacher, a TA, maybe a professor (I have no idea what this is like) – I’ve found that it always helps to take the approach from the absolute base case and then work up to something more advanced.
In the series on the WordPress Settings API that I’m currently working through, that was the plan; however, after last week’s final set of comments, I think the series is either going to be a little bit longer than expected, or is going to result in more questions than expected.
This is a good thing – the comments I received thus far ended up pre-empting some of the material that I was going to cover.
This post is part of a series on Sanitization with the WordPress Settings API. Here is Part 1.
Yesterday, I started talking about how to sanitize multiple values with the WordPress Settings API.
The idea behind the post was to kick off a short series of additional posts that expand on some of the object-oriented articles I wrote a few weeks ago. Secondly, the purpose is to show how we can go about taking input from a Settings API-based page and then use conditionals to validate each of the incoming values as well as add errors messages for those that are required.
In this post, I’m going to walk through the process of actually validating information that’s coming from the page that uses the Settings API. In the follow-up post, I’ll talk about how to go more in-depth with validation, required fields, and how to add error messages to your pages.
But for now, we’re just worried about multiple values.
This post is part of a series on Sanitization with the WordPress Settings API. This is the first post in the series.
A couple of weeks ago, I wrote a series of posts on An Object-Oriented Approach to the WordPress Settings API. With the proliferation of the The Customizer, I don’t know what the fate of the Settings API will be as WordPress moves forward, but I know that it’s not going to go anywhere soon and I know plenty of projects that still use it such that they’ll be maintained for a while.
Anyway, the goal of the previous series should be clear:
How to organize files in an object-oriented manner such that you can take advantage of some of the features of object-oriented programming such as inheritance, etc.
Maybe it did its job, maybe not. Generally speaking, I think the posts lead to some generally positive comments and I had a few people email me with some better questions so I thought I might talk a little bit more in-depth on things we can do to further take advantage of object-oriented practices within the context of this API.