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.
Architect the ConfigStore – Part 1
Let’s architect our configuration store. We’ll start with identifying what it’s purpose is and why it exists. We’ll look at it from a reusable mindset to ensure that it can accept any configuration, as long as it follows our defined structure. In Part 2, we’ll walk through developing the structure of our API in procedural format. The intent of our store is: Load a configuration file from the filesystem one time only. Load the configuration into our store (container) – one time only. Retain the configuration in the store such that it’s available in the app to get parameters throughout […]
Configuration Model – Save Parameters
Let’s finish our configuration model by extracting what the save function needs. We’ll also do a little refactoring work, though this function will need a lot of refactoring and improvement later in this lab.
Configuration Model – Add Parameters
Let’s start mapping out our default configuration model. We’ll start with the add/register meta box function.
Plan It Out
Before we build anything, let’s sit down and plan out what we are going to build. We’ll take a high level, big picture view of we are trying to accomplish and then map out the buildable blocks.
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 […]
Add Another Meta Box – Portfolio
Let’s demonstrate the amount of work it takes right now to add another custom meta box. Hmm, let’s add a portfolio details meta box to collect the client’s name and URL.
Code Review – Repeating Patterns
Let’s do a code review of the plugin as it stands now with 2 custom meta boxes. What do you see? Repeating code patterns. Right? Both the subtitle and portfolio details meta boxes have the same code patterns. Why is that problematic? Think about it. It takes your time to refactor the first implementation to make it’s function names unique. It takes your time to copy the first implementation to another and then change all of the specifics including the callback function names. That editing time is exponential by the number of implementations, i.e. your time x number of meta […]
Lab Introduction
In the last lab, you and I built a custom meta box for the Subtitle custom fields, adding the feature of subtitles for posts. What happens if you need to add more than one meta box to a project? Using the code from the last lab, you would have to copy and paste the meta box file, change what’s different and each of the function names, and then create a new view file. In doing so, your code is redundant with repeating code patterns. Plus, it takes you time to make the codes, meaning an error could occur. What if […]
Better Saving Strategy for Multiple Custom Fields
Our code has a lot of redundancies in it. Moving to a single meta box key within $_POST allows us the ability to refactor our code and build a loop to remove the redundancies. It also makes it easier to merge the incoming data with defaults. Why would we want to merge the data with defaults? Think about that checkbox. When it’s not checked, that key and value will not be sent back to the web server and will not be in $_POST. To ensure that we are working with all of our meta box’s metadata (custom fields), we merge […]
