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’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.
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.
This episode is different. In this one, we’re talking strategy. It’s time to think about how we should approach setting the theme’s version. Should we use the minified or full stylesheet? Does it matter? Hmm, first, we need to look at how WordPress does it. Then we’ll look for a mechanism to change between the files. Let’s walk through WordPress Core and look at how it extracts the stylesheet’s version. We’ll explore wp_get_theme(). Spoiler alert: there is no mechanism. Bummer. Okay, then let’s talk through if we need to change our code or not. If you use an automated minifier, […]
Part of Strategy 2 is to grab the stylesheet’s version and use it as the theme’s version. This strategy eliminates redundancy and utilizes the version number that is required in the theme’s style.css header DocBlock. When? You want to use this strategy when it’s time to deploy or release the theme. You don’t want to use it in development or test modes.
In this episode, let’s talk about what a query string is. Makes sense, right? You first need to understand the URL and those additional parts of information. Then we can move forward.
In Part 1 of the Better Asset Versioning, we are looking at the version number that is applied to each asset resource, i.e. our scripts, fonts, and stylesheets. We are highly inefficient with this process. Let’s eliminate the hard coding of version numbers when we enqueue. Let’s build a better strategy for version numbers when in development mode. Let’s automate versioning and improve our build process.
NOTE: There’s no video for this episode. Congratulations! Look at what you just did and learned: Created a modular architecture for your styles You broke up the standard style.css into partials and then modules. You actively refactored using the Sass-y way to get rid of the redundancies. You started using variables. Seriously, you did great! Be proud. Own it. Now go take a break and chill out. So what do you have in your hands right now? A working Sass architecture. Yup, right now, you can run a task runner and have it compile to native CSS. Isn’t that awesome! […]
The prevalent design pattern at the moment is to move the media queries into the partials and right where the components and styling attributes are. Why? It makes much more sense to have all of your styles in one place for each attribute/component. Think about it. Instead of having all of your media queries (responsive) styles at the bottom of the stylesheet, now it’s nested right with the attributes/components. No more having to jump around to find stuff. It’s all together within the module itself. That makes so much sense. Doesn’t it?
Let’s continue now by working on the footer widgets and site footer area.
Let’s migrate the entry content area, comments, pagination (which is really navigation), and sidebars. You will have three separate modules with when you’re done. You will continue improving your refactoring skills.
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.