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
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:
- Register the setting, the section, and the field
- Display the content on the screen that corresponds to the settings field
- Sanitize the data as its saved
- 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.
- An Interface For The WordPress Settings API
- Defining An Interface For The WordPress Settings API
- Implementing An Interface For The WordPress Settings API
- Inheritance With The WordPress Settings API
- Data in The WordPress Settings API
- Organizing Files For The WordPress Settings API