Part 2 of a series on differentiating content. We need a way to provide contextual information about the content and give readers additional mechanisms to explore and discover content. WordPress provides us with taxonomies and their terms.
What if someone needs to specify some of the labels, but s/he wants the remaining ones to be generated? Hmmmm, that’s an interesting notion. It seems like a valid optional feature that someone would want from your plugin. Let’s build that feature.
Whew, now it’s time to refactor the label generator function. Our labels are split apart into the three categories. What do we need to do? First, we need to know if we are generating labels for a taxonomy or post type. Then we can merge those together with the shared labels.
It’s time to link the FAQ Module into our new Taxonomy Generator. This episode has a twist for you as you’ll discover the code is repeating between the post type and taxonomy configuration loading. You get to learn about how to use the same callback for two separate filter events and then using current_filter() to determine which one invoked the callback. It’s a slick approach I use often.
Like we did for the post type, let’s extract the runtime configuration parameters out of the FAQ Module and move them to the configuration file. You and I will walk through the process together, step-by-step and talk about the strategy of identifying these parameters, the extraction process, and then how to layout the configuration file.
We want to use one label generator for both the custom post type and taxonomy. Why? Because both custom types share a number of the labels, i.e. we don’t want to be redundant. Therefore, before we can refactor the label generator, first we need to audit all of the labels.
Next, we need to move the taxonomy registration out of the FAQ Module and build our generator. Let’s use the same strategy as the post type, where on init we fetch all of the configurations and then loop through them, passing one-by-one to the registration handler. This episode should be very simple for you.
Using term metadata, we can add additional information to terms. We use this information for specific filtering, querying, grouping, and processing tasks. In the back end, we build metaboxes provide an interface for authors to input the details for the term metadata. In this hands-on lab, you will learn the basics of WordPress term metadata, metaboxes, and custom fields you build for their interface.
In this hands-on lab, you and I will walk through the entire process of adding a new feature to an existing WordPress plugin. You’ll start with the Collapsible Content plugin and then add a FAQ feature to it. This feature will require you to plan, think, and execute building a custom post type, custom taxonomy, advanced SQL queries, custom archive, and shortcode.
Next, we need to test our new rendering code. Does it work on each of the pages and only for those that have terms? Let’s test it together. Here is the department taxonomy term rendered into the entry footer of a post: Here it is for a team bio single: Then we need to commit our work to GitHub to save it. Let’s do that together.