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.
Testing is a critical component of your workflow, as it validates each piece of your code to ensure it works exactly as you intended. As a professional developer, testing is a skill that will set you a part and give you a competitive advantage in the marketplace. In this hands-on lab, you will be building unit and integration tests as you learn the basics of PHP testing.
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.
WooHoo! You did it! I’m so proud of you. Whew that was a long, long lab. But it was more than just building a reusable meta box module. My intent was to help you learn about: the Reusable Mindset – developing how you think about software, quality, and costs Architecture – developing how you layout your code Advanced programming concepts for filtering, merging, recursively merging and replacing, and remapping of arrays, as well as assigning a callable to a variable and then invoking it. Tell me what you think Now I want to hear from you. What do you think? […]
We’re nearly done with our save functionality. Let’s walk through it and talk about how it works. We’ll also manually test each piece of it to ensure it’s performing as expected (i.e. expected behavior). We’ll fix a problem too. We’ll also talk about and explore how to assign a callable to a variable and then invoke it like this: Here’s the link to Callable in Docx for you.
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.
To make our save functionality reusable, we need to remap our custom fields’ configurations to rearrange and group them into defaults, delete state, and sanitizer function. Although you could do it in the configuration model itself, that requires you to be redundant, repeating the meta key over and over. Don’t do that. Instead, let’s build a function that programmatically remaps (rearranges) what we need for our save by grouping the keys together.
We abstracted the code that checks all of the various states to determine if it’s okay to save the custom fields into the database, i.e. continue processing the meta box. In this episode, you’ll add new checks for autosave, ajax, and cron (future posting).
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 […]
Let’s get our configuration from the store. We’ll work on error checking too to handle when the store key does not exist. Next, we’ll work on getting a specific parameter from the store and handling error checking. Time to throw an Exception and develop your own error messages.
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
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.