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.
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.
Test, Fine-Tune, and Wrap it Up
Let’s test our plugin to make sure everything works as expected. Open up your browser and go to the Console tab. Look for errors. If you find an asset not found error, you’ll need to explore why. I found when testing that Yoast SEO has an admin stylesheet that has the version number as part of the filename. That causes a problem. Therefore, I added the enqueued handle to my configured list of assets to skip. If you want the final code for this project, click here to view it on GitHub .
Hook into WordPress
We need to hook into a filter event within WordPress to change the stylesheets’ and scripts’ URL. How do we find this hook? Let’s talk about a strategy first. And then let’s look in WordPress Core to see where it’s fired and what arguments we will get when our code runs.
Start the URL Converter Class
Let’s start building our URL Converter class, i.e. the class that will handle checking and then converter each assets’ URL. You and I will layout the basic structure of the class including some of the starter methods and initializers. We’ll create a runtime configuration file that will get passed to the object, allowing us to change the implementation. Then we’ll add the code to the plugin’s bootstrap file to launch, load the configuration, and then create (instantiate) the URL Converter.
Versioning Utility Helper File
In Part 1, we built a versioning utility helper file. We installed it into multiple themes. Let’s move that to our new plugin. Resources Ins and Outs of Namespace for WordPress
Planning Our Plugin
Let’s plan out our plugin. There are multiple features and considerations that we need to think about before we start writing code. In this episode, we will talk about the strategy of reducing redundant code and how to architect a custom site. We talk about why using the same file embedded into each theme and plugin can increase your costs, risks, and time. Then we’ll talk about the different tasks that this plugin will do, including: Move the versioning utility file out of the theme, i.e. that we built in Part 1, and put it into our new plugin. Strip […]
Convert into Utility File – for Reuse
The code that we’ve built is a utility file. But for it to be reusable, we need to do the following: Remove the enqueueing callback and put that into a separate file. Protect the utility functions from loading into memory if they’ve already been loaded by another plugin/theme. In this episode, we’ll do some refactoring and housekeeping. But you also get to learn about this design pattern and why it is so critical in our strategy: In this episode, you’ll refactored in the Twenty Seventeen and Genesis Sample themes. Plus, we’ll demonstrate including our new utility file into a plugin […]
Lab Introduction
Let’s do a quick review and talk about what you will be doing in this lab. Then let’s get the starting boilerplate code installed in your plugins folder. Steps: Open terminal (or Git Bash on Windows). Navigate to your sandbox’s wp-content/plugins folder. Then type: git clone https://github.com/KnowTheCode/better-asset-versioning.git Type: cd better-asset-versioning. Delete the better-asset-versioning folder (it’s the final version of this plugin. Then copy the files from the lab-starter into the root of this plugin. Those are the boilerplate starter files. Here is the repository on GitHub.
Remove Query String from Static Resource URL
In Part 2 of the Better Asset Versioning series, let’s dive into how to remove the query strings, i.e. the ?ver=1.0.0 from the static resources. Static resources are the scripts, fonts, styles that we enqueue. When you run speed tests on sites like Pingdom, a common ding to the performance score is this very topic. Let’s build a plugin that removes the query string and places it inline as part of the static URL.
Applying It to Scripts
We’ve done the theme’s stylesheet. Now we need to apply the same strategy to the scripts and any remaining supplemental stylesheets. In this episode, you and I will refactor the Twenty Seventeen’s enqueue code while we discuss the strategy. Step-by-step, we’ll work through it together. As we do, we’ll find a flaw in our original code.