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.
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.
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.
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
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 […]
Congratulations! You made it! I hope that you learned something new in this hands-on lab. This lab went through: Why we need versioning How to automate it Why automating saves us so much time and frustrations New design patterns How to make a reusable utility file and so much more If you have any questions or just want to discuss what we did, reach out in the Pro Forums. I’m here to help you.
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 […]
Let’s make the same changes and load them into our Genesis child theme. Try to do this on your own first. Then watch the video and work with me.
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.
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.
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.
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.