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 […]
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 […]
The bulk of the heavy lifting for working with meta boxes can be generated using a reusable module. In this hands-on coding lab, you will convert the meta box plugin you built in the Basics lab, making it configurable and reusable. Build it once. Then reuse it. For each custom meta box, build a configuration and view file. That’s it.
Congratulations! You did it! You built a custom, from scratch meta box for a common task of providing a subtitle for your client. Looking back at the code, there’s a lot of boilerplate logic. That means with a few lines of code you were able to create a custom implementation. Notice that we hard-coded in the configuration information. That means we have an opportunity to create a reusable boilerplate and meta box generator function, that you can use on every project. We’ll do that in the next lab.
The last parameter of the add_meta_box function gives you a mechanism to pass an array of arguments from the add/register component to the render function. It gets added into “args” element and is the second parameter in our render_meta_box function.
There are 2 arguments you can set to position your meta box on the screen: $context $priority – the priority within the above content For the context and a post type screen, you can position your meta box within the normal, side, or advanced locations.
Think about an array. The data being posted back when you click publish or update is stored in an array within the superglobal $_POST (i.e. within the web server and PHP). It’s an array of content. Okay, now think about grouping and namespacing. Does it make sense in your mind that we have one key for our meta box and therefore, one entry in the $_POST? Think about that. That meta box key then would have an array with all of our custom fields’ values. Walking down that thought process, how could we implement this strategy? What are the advantages […]
BEFORE sending any data to the database, you first want to validate that data and then sanitize it. Why? To protect the integrity of the data. Before we save, we check that the data is what we think it should be. That’s the validation part of the process. Then we run it through a sanitizer process to strip out anything that shouldn’t be there, including nefarious bad stuff that could cause an expected and potentially dangerous experience in the browser. Let me show you in this episode what happens if a script gets stored into the database and then it’s […]
If we do not get our meta key back within the $_POST, then we can infer that our meta box does not exist on this screen. That means there’s nothing for us to process in the database. Let’s put code in to check that key. If it’s missing, then bail out.