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

In the last post in this series, I showed how to define a base class that represents some of the attributes and functionality our Dashboard class should have, and then I showed how to use inheritance in our Settings class so that we can take advantage of some of that functionality.

This post is going to include a little bit of redundant code, but the purpose of doing that is to show how the display, sanitize, and partial all fit together, and it’s done to help reinforce how the Settings API uses all of these features to read and write information to and from the database.

If you’re familiar with the Settings API, this post may not be as of much help; however, if you’re still new to it, then it may be worth reading.

Ultimately, the purpose of the post is to get us closer to have a fully working plugin that uses some basic object-oriented concepts as well as having a well-organized plugin that will help to contribute to maintainability.

Continue reading

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

In the previous post, we began to implement the interface that we’re using to help guide our integration with the WordPress Settings API. The problem is, we’re not yet at a point where we can see the result of our work in the WordPress dashboard.

But at this point, we’re at a point where we can begin adding an interface for our plugin, but we can also define a class that represents the dashboard.

Additionally, we can have our Acme_Company_Name class not only implement the interface we’ve defined, but we can extend the the class that we’re going to create – that is, we can inherit from it so that we gain some of its properties and methods (if needed).

It sounds like a lot of work and though we’ll be adding several new files and adding a bit more code, we won’t actually be writing that much code.

Continue reading

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.

Continue reading

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.

Continue reading