I think it will best to start with extracting the runtime configuration parameters out of the codebase and move those into a configuration file. Let’s walk through the process together, step-by-step and talking about the strategy of identifying these parameters, the extraction process, and then how to layout the configuration file.
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.
Internationalizing the Collapsible Content Plugin – Part 5
You built a custom WordPress plugin. You used the internationalization functionality from WordPress. But now you want to go to the next step to prepare your plugin for the market. It’s time dive deep into translations and internationalization. In this lab, you will translate the Collapsible Content Plugin using Poedit, generate the files, and then validate.
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.
Build the Shortcodes Configurations
We have three shortcodes: QA, teaser, and FAQ. Let’s move their configurations out of the codebase and into their own configuration files. We’ll walk through creating the files and adding in the new parameters we specified in the last episode.
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.
