This is the third post in a series on An Object-Oriented Approach To The WordPress Settings API. Part 2.

In the previous two posts, I’ve covered two things:

  1. Why it’s useful to define an interface for the WordPress Settings API
  2. An example of one such interface

At this point, it’s worth actually looking at what we can do to practically apply this stuff and implement the interface that we defined in the previous post.

Since I’m working on this series one step at a time (and thus, one article at a time), there won’t be anything functional yet however this is laying the foundation of what we’ll eventually be using to power a settings page in the Dashboard.

A Quick Side Note

Given the recent announcements about the Theme Customizer and WordPress settings (as available on both Post Status and WP Tavern), it’s important to note that the work that I’m sharing here isn’t trying to make a pro-options page stance or an anti-customizer stance.

But plugins and themes that we build outside of the WordPress repository may still require settings pages and thus the use of interfaces, inheritance, and other object-oriented principles can make our work that much easier.

Any comments related to the pros and cons of switching to the Customizer from the Options pages will be deleted.

Implementing The Interface

In order to begin implementing the interface, we need to have some idea as to what we’re going to actually going to ask the user to fill out. For starters, we can go with a basic input element that will ask for, say, their company’s name.

So the first thing we need to do is create a class that implements the interface that we created yesterday:

Next, we need to make sure that each function has its own definition.

Registering The Setting

This is arguably the most complex part of the entire process as it requires an understanding of the WordPress Settings API. I’ve done what I can to comment the code here to make it as clear as possible, but if you’re still confused I recommend checking out this guide as well as the Codex article.

The order in which we setup a new setting is that we:

  1. Register the setting
  2. Add a settings section
  3. Add a settings field

Sounds easy, right? As long as you keep that order in mind, following along with the upcoming function implementation (and its associated comments) should be relatively straightforward:

In the code above, we’ve setup a section and a setting to capture our information. We’ll be adding more information later, but this is the first step in actually creating the field that WordPress will display.

Displaying The UI

In order to display the UI, we need to make sure that we have a template for the dashboard that’s dedicated to displaying our settings as well as giving the users the option to actually enter and save the options.

Here’s how we do that:

Notice here that it’s important that we use the proper ID for the settings field as well as the settings section. If you opt not to do that, then you’ll get some erradict – possibly completely non-functional – code.

Additionally, there’s a little bit of work that we need to take care of within the context of the display method, but I’ll be talking about that specifically in another post because it needs a little bit more detail than can be adequately covered here.

Sanitizing The Input

Finally, we need to sanitize the input that the user provides before writing it to the database. This means that we need to strip it of anything that could be considered malicious code.

To do this, we’ll write a sanitization method that will look at the incoming input. If it’s populated, we’ll strip out all tags, safely handle slashes, and use a utility function as provided by WordPress to sanitize the data.

Note that some of this won’t make since until we finish up the display for the user interface. I’ll aim to do that as soon as possible in an upcoming post.

After that, we return the data. Notice that even if the information that’s passed into the input isn’t populated, we’ll return what’s passed in. This is so that WordPress can take care of anything it needs to do before rendering the page to our users.

More To Come

At this point, we still don’t have a functional plugin. In the next article, I’ll show how to setup what we have so far so that it displays the work that was shared in this post (after all, this was a lengthy post considering the amount of code that was shared.

Once I’ve covered the display method, I’ll be sure to post the full implementation here. But in the meantime, we’re at a point where there’s some additional development and refactoring that can be done.

Not only can we begin to bring this plugin to life by displaying it in the dashboard, but we can also begin to organize the directory structure so that it mimics some type of logical consistency that will play well both with PHP namespaces, or with older versions of PHP.

I’ll pickup with this in the next article. For now, this should be your first pass at implementing the interface for the WordPress Settings API.

Series Posts

  1. An Interface For The WordPress Settings API
  2. Defining An Interface For The WordPress Settings API
  3. Implementing An Interface For The WordPress Settings API
  4. Inheritance With The WordPress Settings API
  5. Data in The WordPress Settings API
  6. Organizing Files For The WordPress Settings API
Category:
Articles
Tags:
,

Join the conversation! 11 Comments

  1. Loving the series so far, wish something this clear was around when I first started working with the Settings API.

    • Great to hear, Alex! I’ve a lot more to come (and I’m obviously linking to past work I’ve done).

      Hopefully this and other posts and source code on GitHub will help out :).

  2. Can we expect a “WordPress Settings Boilerplate” at the end of this series? :)

  3. First of all, two thumbs up for coding to an interface! I’m a big fan of coding classes to an interface.

    Second, to make the Settings class modular, you could, do the following:

    Remove all the hardcoding & place into a configuration array.
    Then pass the array into the class during instantiation.
    Pass the config array through a default, wp_parse_args()
    Then use the config parameters where you currently have the hard-coded items, e.g. settings_field, etc.

    Looking forward to the rest of the series.

    Happy coding,

    Tonya

    • First of all, two thumbs up for coding to an interface! I’m a big fan of coding classes to an interface.

      Thank you! As do I. Sometimes, time doesn’t permit it but I’m trying to do a better job of building that into my schedules when taking on projects for clients.

      Second, to make the Settings class modular, you could, do the following:

      Love these suggestions! They’re a little beyond what I want to accomplish in this series, but perhaps I’ll revisit this in a future, advanced series (and be sure to give you props).

      Thanks so much for this comment.

  4. Tom,

    I’ve been digging around quite a bit for the Settings API in respect to a plugin. Am looking forward to the rest of the series

  5. Just wondering why you are using stripslashes() in sanitize() method, considering Settings API already strip slashes from the submitted values (see https://github.com/WordPress/WordPress/blob/master/wp-admin/options.php#L191) before passing to the sanitization callback.

    • To be honest, part of it is a habit of carry over days from pre-WordPress days. That’s a good catch, though. Should probably follow it up with a blog post at some point — thanks!

Leave a Reply