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.
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 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.
Before we move on, let’s stop. We have a flaw in our strategy, specifically in the stylesheet URI callback. Challenge yourself and see if you can find it. Think about it. Part of your work here on Know the Code involves thinking through and planning out code construction. I’m trying to teach you how to strategize, think about code construction, and do problem solving. There are times when we’ll stop and look at potential problem areas. Our code has a flaw in it. See if you can find it on your own.
Now it’s time to port the changes over to the Genesis theme. The code is exactly the same as all that we did was a callback for the “stylesheet_uri” event filter in order to change the stylesheet’s URL to the minified version. Let’s do the same steps to the Genesis theme.
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.