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.
Let’s improve the render function, as we have too much going on in that function. We’ll abstract away the task of fetching the metadata from the database for our custom fields’ values. Why? Our render function’s job is to render the view. It needs the values, but does not need to know how to do it. Rather, just gimme the values for the custom fields. We’ll also add a WordPress filter event to extend our meta data, allowing an external process to filter the values, do some processing, or just run before we render out to the browser.
Our current save function is not reusable. As we’ve done with the register and render functions, we need to remove the implementation and allow the saving process to accept a configuration and then process it. Let’s rethink our save function, split up the different parts, and prepare for how to refactor it.
If we run our code as it is right now, the meta boxes did not appear. Why? Because we only configured what was different in the Portfolio and Subtitle configuration models. We need to merge each of those with the default configuration parameters. Let’s do that in this episode. You’ll be using the PHP function array_replace_recursive to merge all levels within our multidimensional arrays. When you get done with this episode, both custom meta boxes will now render for a post. WooHoo!! Pat yourself on the back, as you did a lot of work to get to this point. Keep […]
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 start mapping out our default configuration model. We’ll start with the add/register meta box function.
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.
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 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.
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 […]