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.
You need to load files. Right? In PHP you use one of these constructs to load a file into memory (which then makes it run): include( ‘path/to/file’ ) include_once( ‘path/to/file’ ) require( ‘path/to/file’ ) require_once( ‘path/to/file’ ) Let’s look at how these work as well as talk about when you want to use one over the other. You’ll try to load a file that doesn’t exist and see that include gives you a warning while require causes the site to stop with a fatal error.
Let’s talk about why and how does WordPress use PHP. Why does it use it? Because it’s a solid programming language for web development. It’s very popular and prevalent and powers the majority of websites. WordPress uses PHP to do all of its processing including figuring out what the URL’s web request is, what to go grab from the database, what files to load and when, validating user permissions, checking options, fetching post metadata, calling plugins, and calling the theme. It uses it to process form fields, image and document uploads, and so much more. It uses it to build […]
In this episode, you will learn why we use PHP as well as what it does. We’ll talk about what a programming language is. We’ll talk about its role in general terms. You’ll see that WordPress is built on PHP. That’s why each file has a .php file extension on it. PHP is a programming language that runs on a web server. We use it because it’s a popular language for web development. We use it because WordPress is built with it. PHP does the following for the web pages on our websites: Processes Builds Sends out to the browser […]
Let’s talk about the goals of this lab and what we are going to do. This is a gentle introduction to PHP for WordPress theme customizers, theme developers, plugin developers, and anyone who wants to get a basic understanding of the PHP programming language. In this episode, you’ll walk through setting up the test website that you’ll use in this lab. We’ll call this site: php-sandbox.dev. I’ll walk you through using DesktopServer, which is the local web server. You can download the free version to use in this lab. It literally takes about 60 seconds to spin up the new […]
To better understand how you get the taxonomies, let’s go look in WordPress Core. You’ll look at get_taxonomies() which is in wp-includes/taxonomy.php. You’ll discover that this construct is merely using the global variable $wp_taxonomies and filtering what you want to view.
Did you know that you can use a template to target a specific taxonomy? And you can target a specific term too. WordPress lets you drill down and build specific user experiences even at the taxonomy and term level. Let’s talk about that.
Which strategy should you use? It depends upon your specific project needs. In each episode, you and I talked about when it’s appropriate to use each strategy. 99.999 times out of 100, you’re going to use strategy 3. Why? It has the following advantages that we’ll talk about in this episode: It’s one line of code It targets the specific page It does not run on every single web page
The fourth strategy is to encapsulate the functionality and abstract it away to a reusable function within your child theme. Let’s do this together. While you could add this function to your child theme’s functions.php file, it’s better to build your theme’s in a modular format. Best Practice – Modular Approach Using a modular approach, you will create a folder in the theme’s lib folder and call it structure. Then in the {child theme}/lib/structure folder, create a new file called footer.php. Here is the code that removes the site footer for each of the pages that you specify: You’ll need […]
Strategy 3 removes all registered event callbacks. Using remove_all_actions(), you are removing or unregistering every single pre-registered event (hook) callbacks. Using this approach, our code then is: When to Use This Approach? This approach ensures that all of the callbacks are unregistered. It ensures that any callbacks outside of Genesis are removed. Why is that important? It ensures there are no wonky or weird renderings in the browser from your theme or plugin. Strategy 2 removed the defaults from the Genesis framework including the opening HTML <footer class=”site-footer”>, the contents of the site footer, and the closing HTML </footer> element. […]
Strategy 2 will remove the individual Genesis callbacks (hooks) for the site footer. It requires you to create a home.php file in your child theme. This is the file that is called for the Posts’ Page. (If that doesn’t make sense, then you need to go do the Front Page vs. Home Page lab.) Now inside of this new template file, this new PHP file, you will add the individual Genesis callbacks to unregister each of them. Let’s go into the Genesis framework and find each of the hooks. Open up genesis/lib/structure/footer.php. Scroll down and find each of the site […]
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.