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.

Working with Data and the WordPress Settings API

When working with data in the WordPress Settings API, there’s usually two things that we need to consider doing:

  1. Saving data to the database (and doing so safely) which has already covered.
  2. Retrieving the data to be displayed on the front-end which will be covered in this article.

As we’ve seen, saving data can be a really simple process; however, it can also get really complicated depending on the type and the amount of information that you’re saving.

Retrieving data isn’t nearly as complicated, in my opinion, if you’re saving things to the options table in a clean, readable way.

Saving Data

Recall that earlier in this series, we saved the data using the following code:

Remember that in this file, we’re doing this:

  1. Setting up an array to that will hold the sanitized version of our code
  2. Storing the value of the incoming data into a $val variable
  3. Cleaning up the $val variable
  4. Storing it in the $new_input array
  5. Returning it to WordPress

At this point, WordPress will take the value of what we’ve returned and write it to the database. This is why it’s so important to make sure that we’re cleaning – or sanitizing the data – properly.

There’s a relationship between the code that you’re seeing here and the view that we’ve defined. So let’s take a look at the code that renders the view and then see how it relates to the gist above.

First, we create what I call a partial (since it fits within the context of a template displayed in the dashboard – it’s not an official WordPress term). Then, we make sure it includes the input field that will contain our Company Name.

We’ve seen this before and it’s simple enough, right? But there’s a few key elements to take away from what the name attribute that’s specified for this element:

  1. The name attribute includes the name acme_company which is the name of the set of options that we defined earlier in the series.
  2. We’ve defined the acme_company as an array having an index of  name so that we can save the data as a serialized array and retrieve it using the same index.

Make sense? If not, no big deal – admittedly, it’s confusing. But once you see how this relates to actually retrieving the data, it should be a bit clearer.

Retrieving Data

Similarly, recall earlier in the series that we retrieved the data using the following code:

But that’s as far as we got. What do we actually do with the code here?

First, it’s important to note that if you were to look into the database, then you’d see a record that reflects our options. Namely, it would have an option_name corresponding to acme_company and then a serialized value representing our company name:

Acme Company in the Database

Acme Company in the Database

We’ve seen how the sanitize method and the partial work together to save the data; now we can see how the display method and the partial work together to display the data.

First, recall the code for our display method:

If we were to trace the code, here’s what’s happening:

  1. Grab the option from the database
  2. Read the value based on the name key as specified in our partial (and as stored in the database)
  3. Set a default value for it in case it’s empty
  4. Render it in the context of the partial

Recall, the partial will look like this:

At this point, you should now see how information is not only saved from the partial, but also displayed in the partial.

Specifically, if you haven’t noticed before, see that the partial unconditionally echoes the contents of the $name value. This is why we check to see if the value is empty before setting it in the display function.

Reorganizing Our Files

Next, we need to consider re-organizing our files. Keeping everything in the root directory of the plugin, although functionality, isn’t a good practice. Instead, we need to have clearly defined directories that mirror the namespaces our code might eventually have (depending on the version of PHP you’re using).

So in the next article, I’ll pause writing any new code and look at how to reorganize the files in the directory so that they match up with the architecture of the plugin.

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

  1. Warmed my heart to see the views off on their own and not intermingling with the tasks code. Excellent series, Tom.

    • Thanks a lot, Tonya.

      Separating those types of things are really important to me especially when it comes back to working with and maintaining these types of projects in the future (not to mention conceptually modeling the information — but that’s another post :).

Leave a Reply

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