Software, Development, and WordPress

An Interface For The WordPress Settings API

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

One of the things that the WordPress Settings API has going for it is that it makes it possible to introduce menus, pages, input elements, and so on into the WordPress dashboard that have a native look and feel.

But if you’ve never dug into the API before, it can be really daunting. It’s not really intuitive, there are some confusing parameters, there is some difficult terminology, and the way in which you go about introducing various menus, sub-menus, pages, sections, settings, and so on can get confusing especially if it’s your first time around the API.

A couple of years ago I wrote a guide to the WordPress Settings API and it’s held up pretty well, but the more we use certain aspects of a language or API, the more we learn, right? At least, that’s been my experience.

And in this series of posts, I’m going to cover exactly that.

Not That Kind of Interface

When we hear the word “interface,” it’s normal for us to think in terms of a GUI, or something has as input fields, buttons, and so on with which we can interact.

And when it comes to WordPress, I think that’s a fair assumption. There are generators for many of the APIs that are available. And I’m not saying that’s a bad thing, but I do think it’s important to learn what’s happening behind the scenes before using them as a crutch for your work.

But that’s content for another post, so I digress.

Instead, I’m talking about an interface in terms of object-oriented programming. In this case, I mean a PHP interface:

Object interfaces allow you to create code which specifies which methods a class must implement, without having to define how these methods are handled.

In short, interfaces allow us to define the methods a class must have if it implements the interface.

Because registering settings and creating displays and fields in the dashboard is so common for the WordPress Settings API, it makes it a perfect candidate for using an interface.

For The Settings API

The WordPress Settings API

Before actually looking at any code, I think it’s worth noting exactly what the Settings API requires in order to create a new setting. And the very least, we need to be able to:

  1. Register the setting, the section, and the field
  2. Display the content on the screen that corresponds to the settings field
  3. Sanitize the data as its saved
  4. Optionally display error messages if the sanitization fails

There are cases in which things get more elaborate, but in the most basic case – which is what I’m concerned most about sharing at this point – this is what you need in order to get going with the Settings API.

And when you have an outline of clear steps like what’s above, then you have what I believe to be a candidate for an interface because it provides an outline for what must be implemented in order for settings to be registered, displays, and sanitized.

In The Next Post

Starting in the next post, I’ll actually begin sharing some code for how to get started with this. Prior to doing so, though, I wanted to make sure I adequately covered the basics of PHP interfaces and the WordPress Settings API both of which I’ve linked in the article.

If you’ve already got a lot of experience with object-oriented programming and the Settings API, then this series isn’t really going to benefit you very much.

However, if you’re looking for a standard way to begin implementing your own settings using the WordPress-defined APIs, then this should be beneficial as it helps to make the code much more maintainable (at least in my experience) by keeping classes small, focused, and carrying only minimal responsibility.

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


  1. Nate Wright

    Hi Tom, you’ve probably got your code already lined up for the future posts in the series, but I thought I’d point you to my own little object-oriented wrapper library for the Settings API, Simple Admin Pages.

    It’d be nice to compare notes once your series is finished to see how we’ve each done things differently. There are certainly a few things I’d change down the line, but I’ve also worked out a bunch of difficult problems — like how to ensure two plugins loading different versions of the library don’t conflict.

    • Tom

      Thanks Nate!

      You’re right – I do have my notes, though I don’t mind you plugging your work either :).

      The approach I’m taking won’t be one that takes a framework approach, though. It’ll be more focused on making a modularized, object-oriented layout of how the code can be written.

  2. Rick

    Hi Tom,

    You took the zip out of my zap! LOL.

    I am new to WP's codebase, more a C#, .net / guy.

    I was just doing some code with the settings api and was thinking the EXACT same thing. At least the Admin end of it. In as far as outputs go PHP is rather ram hungry with oop.

  3. James

    Total newbie here trying to learn the ropes with plugins and at the very least get a solid background on the right steps to take along the journey. So this is extremely valuable here and il try and follow along to the series. I am reading back over the last few posts also and looking through the boiler plate example. Setting out on the journey on a good solid footing is key and this helps heaps!

    • Tom

      Glad to hear it, James!

      It’s a lot to take in at first, for sure, but it just takes time and diligence in focusing on what you’re going after.

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑