Whenever you’re working on a plugin that offers a page for its settings, there are several ways that you can save and retrieve the information.
You can:
- use the Settings API,
- use a custom page and calls that are a hybrid of the two,
- use some type of hybrid between a submenu page (or a menu page) and other functionality.
The more I’ve worked with WordPress, the less and less I care to use the Settings API and opt to go with a bit of a hybrid approach.
Depending on the requirements of the project, the implementation will vary; however, I try to use a relatively consistent way to create the functionality.
And though this post won’t go into the various ways that I create my pages, related classes, and so on, it will offer one way that you can go about initializing plugin settings when working on your project or a project for someone else.
Initializing Plugin Settings
For this post, assume that the requirements call for storing the values of a page as an associative array that’s sanitized and serialized from within the plugin.
Aside from the sanitization functionality that you’re going to need, you also know that you’re going to be working with:
- the options table,
- and, as such, a unique key for the options stored in the options table
Now in the context of object-oriented programming, I normally have several classes set up for handling all of this functionality, but I’m primarily concerned with showing a way to go about initializing plugin settings.
But Why?
If you load a page that’s meant to retrieve options from the database and the values haven’t been initialized, then you’re going to see warnings on your screen, or something shows up in your debug log file.
This all depends on how you have your local installation configured as well as how your host has its configuration defined.
Regardless, you want to make sure that you’ve initialized the plugin settings so that you at least have the row set in the database and initial values or empty values set for the plugin.
How to Do It
As previously mentioned, because I’m a fan of using classes in my work I usually set up a class that’s responsible for reading and writing values to the database. And this includes initializing plugin settings.
To do this, I generally work using the following process:
- initialize the class,
- check to see if an option exists in the database,
- if it doesn’t, then initialize it,
- if so, don’t do anything.
The initial code for doing this may look something like this:
But because this is in its own function, it can be called within the constructor of your class, or you can mark it as public and call it outside the class. For this post, though, I’m placing a call for it in the constructor:
And once the values have been initialized, an attribute on the class can be set:
Though there’s a case to be made that this shouldn’t be done in the constructor, I do like having class properties initialized within the constructor of the said class.
And since the class is responsible for maintaining a reference to the settings, then it makes sense to initialize the settings here.
