In the United States, today is Memorial Day in which we honor and remember those who have died during service to the country.
Page 214 of 427
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.
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.
Occasionally, I’ll get questions via Twitter or email from those who are working with the Settings API and aren’t sure why certain values are saving when they shouldn’t actually be saving.
For example, say you have an input field that’s asking for, say, a company’s name. You obviously want to sanitize the data to make sure that it doesn’t have any malicious characters and you want to make sure it’s empty, but what if you’re code is structured in a way that is stores an empty string in the value of the array if it’s not set?
I mean, an empty string is not nothing, right?
As an industry, computer science and/or software engineering is comparatively young. The field moves fast, no doubt, but we’ve obviously not been around as long as many of the other industries in which our parents or our peers are involved.
I think that’s just one part of what makes all of this interesting.
One thing that I’ve begun to notice about the industry is that the more new technology that is made available with respect to web development, the less people understand about the work that came before them.
It’s kinda sad, but it’s also natural, right? I mean, given a cliché example, each time something new is added to a car, we don’t all necessarily understand what was in place before a new piece of technology, we’re generally just happy that a new piece of technology exists and that it makes our lives easier.
But in the field of web development (and perhaps other types of development – I don’t really know), other developers – specifically those that are newer to the field – do call into question some of the ways that we do things, some of the things that we do write about, and some of the things that we do try to explain because “there’s an easier way” and, as such, it makes no sense to share such antiquated tips.

Bummer.

