Let’s say that you’re working on a plugin that has its own plugin settings page, and on that page there are options to determine what type of posts will support part of the functionality of the plugin.
For example, let’s say this plugin will be introducing a meta box for each post type that extends the type of information that the user can add to a post. The settings page allows you to control which post types will offer this information.
To give a concrete example, take a look at the following screenshot:
Granted, it’s a small example but it makes the point: We have a plugin settings page that displays all of the post types that are in the current theme installation. If selected, we’ll save the values to an options array.
When it comes time to read the values, there are a couple of ways to go about doing it, but one that’s arguably simpler than all of the rest.
Before actually looking at any code, here’s how you can imagine all of this playing out:
- The plugin settings page exposes all of the post types that exist in the theme
- The user has the ability to select which post types should display a post meta box
- If selected, the respective post types will support the meta box
For example purposes, we’ll say that all of the checkboxes are storing their values in an array called
acme-supported-post-types so the way we’d retrieve the selected options would be
get_option( 'acme-supported-post-types' );.
With that said, let’s say we end up on a post (or page or other custom post type) edit screen and we need to check if the given post type supports the addition of a meta box.
One way to go about doing it is like this:
This is long-winded, cumbersome, and leaves a bit to be desired, right? Not mention, there are somethings that some developers would argue is a code smell, but I digress.
To that end, this code can be simplified into a single line:
This returns the same boolean value with significantly less code.
Why Share This?
The reason that I think it’s important to look at example of code like this is two fold:
- Looking at how other people refactor and/or consolidate their code helps us to think more critically about the code we’re writing.
- If the code that we’re writing can be simplified by leveraging built-in libraries and functions in the native programming language, we should consider doing that.
To be absolutely clear: This is not a praise at my ability to write code. That’s arrogant and it’s not my style. I have just as much to learn as the rest of everyone.
Even more so, look through any of my past code snippets, gists, etc., and you’ll see that there’s room for improvement; however, all of this is coming from reading other books, articles, etc., that have helped me to think more critically about what I’m doing, and I’m sharing what I’ve put into action.
As with anything, there are other ways to go about doing this but all of them are dependent on how you end up saving the data. Since I opted to use the Options API, this ended up being the best way to go about doing that.
Of course, there are other examples and ways to go about doing the same thing, this just ended up being the way that I found to be the most readable given the constraints of the project.