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.
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 […]
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, […]
In this episode, you and I are going to test all three shortcodes. Here is the test content we’ll use:
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.
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.
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.
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.
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.
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.