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.
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.
Part 2 of a series on differentiating content. We need a way to provide contextual information about the content and give readers additional mechanisms to explore and discover content. WordPress provides us with taxonomies and their terms.
It’s time for you and me to think about how to make the shortcodes reusable. Let’s put our three shortcodes up side-by-side and identify what each has in common. We are looking for patterns, those clues to identify reusable opportunities.
Let’s stop and talk about our configuration architecture. Does it make sense to have the configuration files in the plugin’s config folder? Or should those be with the FAQ Module? Hmmm, let’s talk our way through both strategies.
What if someone needs to specify some of the labels, but s/he wants the remaining ones to be generated? Hmmmm, that’s an interesting notion. It seems like a valid optional feature that someone would want from your plugin. Let’s build that feature.
Whew, now it’s time to refactor the label generator function. Our labels are split apart into the three categories. What do we need to do? First, we need to know if we are generating labels for a taxonomy or post type. Then we can merge those together with the shared labels.
Right now our Custom Module is embedded within the Collapsible Content plugin. When is that the right decision versus building a standalone central plugin? You will have projects that need more than one custom post type. And these new types may not be related. That means the architecture dedicates separate plugins. FAQ is part of the Collapsible Content. But a Portfolio feature does not relate to the Collapsible Content. Therefore, it would require its own plugin. A testimonial feature is another solid example of an additional custom plugin. Each of these plugins needs the Custom Module. In this use case, […]
Many projects require more than one custom post type or taxonomy. If you are building a typical business-centric website, then your client may need a FAQ, Portfolio, Testimonials, and more. Each of these requires a custom post type. Obviously, you would not want to add a Portfolio module to the Collapsible Content plugin. Displaying your client’s project portfolios to show off their work and services is not related to and does not have the same intent as what the Collapsible Content plugin. Therefore, you would build a separate Portfolio plugin. Let’s move our temporary portfolio code out of the FAQ […]
In this episode, you and I will move the rewrite rules handler out of the FAQ Module and put it into our new Custom Module. We’ll simplify the process during plugin activation by removing all the code and replacing it with delete_option( ‘rewrite_rules’ );.
Next, you and I need to build a registry mechanism for our custom post type generator. We need a way for plugins to hook into our custom module and pass each custom post type’s configuration to us for processing. Let’s talk about the different approaches to achieve this feature. There are different strategies that we can use: Use the WordPress event-driven engine by building a custom filter We could build a configuration store. For the custom post type, let’s build a custom filter event. Later for the taxonomy, we’ll build a configuration store. Why? I want to give you two […]
Know the Code develops and empowers professional WordPress developers, like you. We help you to grow, innovate, and prosper.