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

Yesterday, I started a series in which I’m planning to layout to how to use some basic object-oriented practices to work with the WordPress Settings API.

Though I’ve covered the API in-depth before, I’ve found that there are ways we can further improve a project’s architecture if we stick to some guiding object-oriented principles. But in order to do that, it’s important to understand certain things such as classes, interfaces, and functions that are public, protected, and private.

For many, these are well-known concepts, but for others who are just jumping into the world of object-oriented programming (let alone WordPress), it can be a lot to take in and even more daunting to ask for help.

So I’m planning to take this post by post (or step by step or what have you) in order to make sure I cover as much ground as possible without overloading anyone. Oh, and questions welcome.

The WordPress Settings API

As mentioned in the previous post, there are three things that must be done in order to work with the Settings API. You’ll need to register:

  1. The section
  2. The setting
  3. The field

And once that’s done, you’ll need to define a way to not only display all of the information related to your your setting, but you’ll also need a way to sanitize the information to protect it from the database.

All of that will be covered in future posts. Today, we’re primarily focused on understand interfaces and understanding how to construct our first interface.

A Short Primer On Interfaces

According to Wikipedia, a class interface is:

In object-oriented languages, the term interface is often used to define an abstract type that contains no data or code, but defines behaviors as method signatures. A class having code and data for all the methods corresponding to that interface is said to implement that interface

In short, class interfaces define the methods that any class that implements that inferface must implement the methods.

For example, let’s say that you have an interface for a 80’s device called a Stereo with method signatures for stop, play, rewind, fast forward, and pause. This methods that any manufacturer who wants to make a Stereo must provide functionality for methods named like that.

Stereo Interface

This probably one of you rocking out back in the day.

Make sense? Let’s see it in action.

An Interface For The Settings API

Given what we have above, a that implements the Settings API must do the following things:

  1. register sections, fields, and settings
  2. display the information to the user
  3. sanitize the information when the options are saved

So what would an interface in PHP look like? Perhaps something like this:

For those who are unfamiliar with interfaces, you’ll likely notice two things:

  1. The file is declared with the interface keyword (rather than class keyword)
  2. The functions have no definition

Recall that this is because an interface responsible for providing the methods that implementing classes should define. You can instantiate an interface. The method signatures don’t do any work.

But what does that even mean?

In the next part of this series, I’ll take a look at what it’s like to actually implement the interface by defining a simple setting and then rendering it to the display.

In the meantime, feel free to ask any questions that you have about the code linked above.

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! 8 Comments

  1. Hey Tom,

    I really am enjoying this new series. But what concerns me is the part where PHP 5.2 doesn’t support interface methods. What do you think about that?

  2. Hi Tom,

    Thanks for this descriptive tutorial. It’s too long but I try to follow every steps. Please clarify one thing, isn’t this true that I need to wrap all register setting, callback and validate functions inside a certain function and hook the wrapper function into admin_init hook? If it’s not true, how should I call those functions? I had read the steps but couldn’t figure out. Help me please.

    • isn’t this true that I need to wrap all register setting, callback and validate functions inside a certain function and hook the wrapper function into admin_init hook?

      In a mnner of speaking, yes. But adding everything to register would be better if you have a private method that took in a few parameters, then you have a collection of arguments for each of your settings. Then iterate through that collection and call the private method once.

      Next, if you see in the tutorial, depending on your implementation you won’t need to do anything with add_action because the plugin will fire when its instantiated. If you’re using procedural programming, then you’ll need to using admin_init but you can read more about that in the Codex.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.