In the United States, today is Memorial Day in which we honor and remember those who have died during service to the country.
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.
When working with WordPress menu page permissions, you there’s a chance that you’ll eventually come across the “Cheatin’ uh?” message.
In short, this particular message shows up whenever a user of a certain role with a certain set of capabilities is trying to do something that they aren’t permitted to do. For example, say that you have an Editor who is trying to save options on a page created by the Settings API.
Technically speaking, this should be straightforward:
- Create the options menu (via, say, add_menu_page)
- Populate the page using the Settings API
- Allow the user to save the information
add_menu_page, you have to specify a capability for which the user has the ability to save the options. Luckily, the Codex has a page that makes it really easy to know what capabilities are available to each role.
But what happens when you’ve defined a capability for a menu page and you’re still getting an error message when trying to save the data?
Occasionally, I’ll get questions about how I handle what it’s like working from home and running a business all the while having my family at home during the day (my kids are both three and one so they aren’t quite at school age yet).
So though this has nothing to do with development and has more to do with how I get things done, I thought it would be worth sharing within the context of a blog post so I’d have something to refer to others later in terms of how I manage my environment and my time when it comes to working out of the home full-time.
When working on software development projects, there are certain things that I think every project needs. Sure, each project is different so there’s definitely a difference among projects, but in my experience there are a few things that are crucial to both managing a project and completing a project.
Honestly, when it comes to writing posts like these, I think our natural tendency is to do so from the perspective of a freelancer or someone who may be subcontracted or self-employed.
Though I tend to fit in the latter camp, I’ve found that the following tends to be true regardless of where you work – be it a big corporation, a small team, or even on your own.
With the recent change to WordPress.org requiring themes to use the WordPress Theme Customizer in their work, WordPress designers and developers have been talking about it and discussing it for several weeks now.
And rightly so: Many of us are fans of the customizer, many are not, some fall in between, and some wish that there was a compromise.
As far as I’m concerned, that’s fine (though maybe I’m biased because I tend to be a fan of the Customizer), but whatever the case, this doesn’t change the fact that there’s a lot of education that needs to happen around how to use the API – which isn’t terribly difficult (in comparison, to say, the Settings API) – and how to make the transition over to it.
Though we can do some really cool stuff with it, it’s not my favorite API to work with. Perhaps I’m missing something, but I don’t find it particularly intuitive and it takes me longer to read through the documentation to figure out how to do something that seems as if it should be simple in comparison to some other languages’ documentation.