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.

Pausing WordPress Settings API Validation

Pause on the WordPress Settings API

For example:

  1. Danny left a great comment about the redundancy of what we’re doing in terms of the redundancy for the foreach loop. If you’re looking to shortcut you’re learning of PHP, then read this comment and maybe take a look at the PHP manual.
  2. David left another great comment regarding the array_map PHP function that utilizes PHP closures (of course, this isn’t eligible for all versions of PHP) but it’s worth a read for those of you who are using compatible versions.
  3. Rick left a comment about the work he’s done in prior work and how it’s applicable to what we’re doing in the WordPress Settings API.

To be clear: These comments are fantastic and I love seeing them. The only thing that the adds to the series is that some of the upcoming content maybe redundant for those of you who are looking to learn as much as you can about the data sanitization aspect.

But that’s okay! I asked for this, right?

That said, this is one method that I’ve found to be very effective. If other people chime in with their own comments linking to other code, be sure to review it – you (and I!) may learn something even better.

And that’s the great thing about having smart, engaged readers who offer up suggestions before you even get through all of the content.

So What’s Next?

Right now, the plan is still to continue as normal:

  • We’re going to look at some of the redundancies in code
  • How we can handle required cases and error messages
  • How to prevent data from being saved until the user has entered all required information

So this is a bit of a weird, unplanned post and it doesn’t really contained a lot of educational material on it’s own, but I do ask that you read what the previous commenters shared as it’s valuable material that, at the very least, will help us move along as we continue to work through this series.

Thanks to those who are reading, comments, and so on. And so while I’m hitting pause (until tomorrow, that is), if there is anything confusing up to this point, feel free to leave a comment so that I can try to address it in future posts.

Until Part 4.

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

Join the conversation! 2 Comments

  1. After my struggle here (stupid typo actually!) with Post Types NOT working (I am SO SO SO used to .NET LOL being my grandmaster helper) I built out a few classes for Post Types, Taxonomy, Meta’s that make things a bit more efficient (and certainly more pretty).

    I really really am not a fan of Singleton design patterns. Most often they are used in databases with PHP where-as the true answer is DB Pooling. But, with WordPress being this sorta hybrid/procedural deal I find the singleton again useful.

    The nice thing is of course encapsulation, extensibility, cleaner code, knowing WHERE things are in the codebase and perhaps best, small footie-print.

    So in this post-type / taxonomy gig… lots of labels. Lots and lots and lots of labels. This is the case as well across many other WordPress function on the Admin end mostly.

    So, a small singleton class that just consumes some passed arrays of single name, plural name and in the case of taxonomy collection name. Just plows through the labels in a loop and only does so when needed (is_admin). Labels simply have a prefix, “@” for single, “#” for plural trimmed when interpolation occurs.

    A small set_data function allows for modification of any label or attribute from anyplace since its a static class. Within other classes or outside a class in procedural code.

    More handy dandies. Since WP need consume the array of labels / attributes one can also add in ones own. For example, a template filename to then be included in WP’s get_template function or other data keeping in all nice nice in the array. Essentially, it still allows that sorta WP Multi-use pocket knife type scene that WP really is.

    From what I can recall from the other codebase I spoke of the data to be run through the washing machine and its constraints were described in an XML file right along with the form (or any data for that matter). It simply iterated through the non sanitized data. These was a common sanitization core class for things such as numeric, ranges, alphnumeric, alpha, escaping etc. For ordered data such a phone number, addressing, a complex form with say like UPC codes where data need meet formatting requirement those functions were loaded on the fly based on what the form needs are.

    Just iterate through em’, based on the name of the input. nm_age being a numeric and in the XML be “age” and the constraints min 21, max 100. For say phone, ph_phone and in the XML file would reside the regex pattern and the function name for the regex class (extending the common base class) and filename to pull in.

    All using a common exceptions class to feed back info to the user.

    After passing sanitization and ready for the database (or other functionality) we’d strip the prefix and replace it (if need be) ready for its next stage in processing.

    So for example, say the form is an address for snail mail campaign materials .vs. say a volunteer or campaign contribution etc. all requiring like data but very different in purpose. We use the one common form, then in post sanitization processing prefix it all, “smail_addressing” or “vol_addressing” or “contrib_addressing”. Now we have the data to do the right table “Select” and the write to the table fields still keeping our naming conventions organized both in code and more so the DB as given tables need be exported proper for the CRM they are needed for.

    In preprocessing the XML to output the form dynamically we’d send off the common javascript to stop the banging on the server for things such as required fields, numerics, etc. as well. Pre-sanitization sanitization pretty common these days.

    People tend think forms not really too awful complex but they really can be. Part of the reason so many open holes exist in web apps is because they are not looking at forms processing in an encapsulated fashion. In our code, the XML basically provides several maps. One for the form creation, the other what to do after submitted.

    Thus we know, if we have a problem, its not interspersed someplace of “who knows where”. We know its in that code.

    I plan on extending this “Post types / taxonomy / meta” stuff to use XML possibly json as well. Easy nuff’ to do once one has one or the other.

    In .NET as you know Tom, how much code is devoted in a Windows application to dealing with the user interactivity with it? Lots.

  2. @Rick : TLDR – OOP can be complex. You don’t like Singletons. You like XML. .NET + Windows = Sadomasochism.

Leave a Reply