Page 215 of 428

Sanitizing Arrays: The WordPress Settings API

May 22, 2015 / Tom / 0 Comments

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.

Sanitizing Multiple Values with the WordPress Settings API

May 21, 2015 / Tom / 0 Comments

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.

How To Stop Saving Empty Values with the Settings API

May 20, 2015 / Tom / 0 Comments

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?

Assume You Know Nothing, Learn Even More

May 19, 2015 / Tom / 0 Comments

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.

That's Borderline Inappropriate

Bummer.

WordPress Menu Pages and “Cheatin’ Uh?”

May 18, 2015 / Tom / 0 Comments

When working with WordPress menu page permissions, you there’s a chance that you’ll eventually come across the “Cheatin’ uh?” message.

Cheatin uh

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

When defining 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?

Tom McFarlin

Sanitizing Arrays: The WordPress Settings API

Sanitizing Multiple Values with the WordPress Settings API

How To Stop Saving Empty Values with the Settings API

Assume You Know Nothing, Learn Even More

WordPress Menu Pages and “Cheatin’ Uh?”