We’re done with our plugin, but we do have an opportunity for optimization as well as housekeeping. It’s a good practice to walk through your code when you’re done to: re-evaluate look for optimization opportunities do some housekeeping like commenting, formatting, and cleanup and ensuring everything in a file supports the intent of that file. Let’s walk through our Metadata Module together.
In the last episode, we saw the ‘meta_key’ configuration in our custom fields. That is coming from our default configuration model. Since there’s nothing to overwrite it during the recursive merge in the configuration store, it is added into our configuration. How can we remove it? Let’s talk about that in this episode. We’ll talk about protecting your module’s code when selecting the strategy to implement.
We have a problem with our architecture. Do you know what it is? We have no way to differentiate and fetch only the keys for a specific component or module. In your work, you’ll likely have multiple modules using the ConfigStore. For example, you may have shortcodes, widgets, meta boxes, and custom post types all loading configurations into the store. How can you get only the configurations for the meta boxes? Right now, you can’t. In this episode, we’ll walk through a refactoring process to provide the means of fetching keys for just that component or module level. You’ll add […]
Continuing from Part 1, let’s layout our configuration store’s module, api, and internals. We are going to design this module in procedural, although you could design it in class wrapper (static functions within a class structure) or OOP. We’ll use a static variable to be our container. Resources Static Variables in PHP Static Variables – PHP Internals PHP Manual – Static Variable
Let’s test and figure out how to load a configuration file from the filesystem and get it into our configuration store. We’ll do this together step-by-step, systematically discovering how to load, how to extract the store key and configuration parameters, and thinking through our store. Resources In this episode, you’ll use: current() key() list()
We have a structural error in our configuration models. Oh bummer. Did you notice it? In this episode, let’s fix all 3 files before we move onto the Configuration Store.
We’ve completed our meta box configuration model. Now, let’s take that model and load up our 2 custom implementations. You’ll want to store each configuration file into the config folder. If the plugin was doing more than a meta box, then you’d put the configs into config/meta-box folder. Resources intval sanitize_text_field
In the last episode, I challenged you to complete the render parameters yourself. In this episode, we’ll walk through how I solved it. We’ll fill out the custom fields in our Configuration Model. Plus, we’ll refactor our render function for our new generic, configuration business logic.
Let’s layout the basic architecture of the configs, config store, and metadata. Work along with me in the video to get your plugin architecture setup and ready for the remaining parts of this lab.
As you are developing your Reusable Mindset, I want you to think about implementation and business logic. More specifically, think about how to separate a specific implementation from the business logic. This design pattern makes your code reusable. For example, in our project, we have 2 custom meta boxes. Yet, both are using the same code. Imagine pulling the implementation out of the code and abstracting it into a configuration file. Now imagine that our business logic is rebuilt to accept a configuration file and then it processes it. Why? In doing so, our business logic is built once. It […]