Let’s wire up our meta box and module to load the configurations and then go fetch what we need. We’re getting closer to having a working reusable metadata module for multiple meta boxes.
Labs
Labs are hands-on coding projects that you build along with Tonya as she explains the code, concepts, and thought processes behind it. You can use the labs to further your code knowledge or to use right in your projects. Each lab ties into the Docx to ensure you have the information you need.
Each lab is designed to further your understanding and mastery of code. You learn more about how to think about its construction, quality, maintainability, programmatic and logical thought, and problem-solving. While you may be building a specific thing, Tonya presents the why of it to make it adaptable far beyond that specific implementation, thereby giving you the means to make it your own, in any context.
The Reusable Mindset
Let’s talk about code reusability and the reusable mindset. The first step is to identify repeating code patterns where you can separate the implementation from the code. The next step is abstract the code, building it in such a way that it can accept an input(s) to pass in or configure the implementation. Then this black box code that you’ve abstracted handles everything for you based upon the input you provide and delivering an expected behavior every single time. For our code, imagine moving the meta box add/register, render, and save functionality into a module that generates your custom meta […]
Wrap it Up, Review, and Commit Changes
Let’s do a little clean up before you commit these changes. Then let’s commit the final changes to your GitHub repository. What’s the whole point to the ModularConfig architecture? The point is to help you to build your projects faster. ModularConfig puts code to work for you to generate code for you. It abstracts away redundant code so that you have less code to build, test, and maintain. It saves you a ton of time! What happens when you remove the common tasks and redundant code? What happens? It takes less code to build your projects. If a bug happens, […]
Test the Shortcodes
In this episode, you and I are going to test all three shortcodes. Here is the test content we’ll use:
Shortcode Configuration Store
Let’s build the shortcode configuration “store” and then the API wrapper functions to work with the store. The store does two separate functions: Stores configuration by the shortcode name as the key Get the shortcode configuration out of the store by its name (key) We use a static variable to retain the array of stored configurations, as a static retains even after the function completes.
Registering Shortcode with Custom Module
Next, let’s work on the registration handling within the Custom Module. This function needs to do the following: Loads the configuration file for the shortcode. Merge the configuration with the defaults. Add the shortcode and its callback. Store the configuration. In this episode, you and I will complete the registration code. Then we’ll register all three shortcodes from our Collapsible Content plugin.
Starting the Shortcode Boilerplate
Let’s start by building the beginning of our Shortcode boilerplate within the Custom Module. This boilerplate code will be responsible for: Registering the shortcode configuration from each of the modules, plugins, and/or theme within your project. Loading each configuration file into memory. Storing the configuration for the shortcode to access. Registering the shortcode and its callback with WordPress, i.e. add_shortcode and processing and rendering the shortcode’s HTML. Let’s walk through the thought process together step-by-step.
Test the Taxonomy
Let’s test out all of our new code and make sure everything works as intended. There will be a few typos and boo boos. You’ll see me think through when I’ve made a mistake and find the root cause.
Auditing the Custom Labels
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.
Generate Post Type Labels
Custom post types and taxonomies both need custom labels to improve the user’s experience with the back-end interfaces. They both share some of the same label structures. Therefore, it makes sense to build one custom label generator that serves both the taxonomies and post types. In this episode, you will move the label generator out of the FAQ module and into the Custom module. You’ll be refactoring the code to accept the runtime configuration parameters.
