Let’s talk about why we want an API for this component. Some of the reasons include: Developers using the Data Store do not need to know the implementation. They don’t need to know if it’s built in OOP, static class, or procedural. Rather, the API wires to the Data Store. It hides away the implementation, exposing public facing procedural functions to interact with it. Future proofs your work. Makes it easier to work with the Data Store.
Labs
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.
Global, But Controlled Access
We want our data store to be globally accessible to all plugins and the theme. But we want to control the access and interaction with the items in the store. Let’s talk about why both of these are important features.
Defining the Container: Data Type & Retain
Let’s define the container’s data type and how to retain the items in the container. There are different strategies: JSON file database in-memory cache – such as Redis in-memory using a PHP data type We’ll discuss the problems and strengths of each. If you’d like to learn more about in-memory PHP data type, checkout the Array Data Type in the PHP Docx.
Identifying Items in the Store
Let’s discuss strategies for identifying the items in the data store. In this episode, you’ll: Figure out all of the important attributes for our identifiers Come up with a naming convention that supports those attributes More Information If you are interested in learning more about identifies, an Array Data Type in the PHP Docx is a great place to go. Check out the “Understanding the Keys” section to discover more about unique identifiers, which in this case is called a key.
Document the Basics
Let’s document the basic attributes and functionality we discussed in the last episode. Here’s what you’ll be doing: Get overview of markdown. Here’s a link to a Markdown Cheatsheet. Add a docs/requirements/basics.md file to the plugin. Create a new branch with git. Commit the changes into the branch. Note: If you don’t have the git aliases set up yet on your machine, then stop here and go do the Git Productive lab. It will speed up your workflow.
Defining the Basics of a Data Store
Let’s define the basic attributes and functionality of the data store. You’ll walk through the internal characteristics of the store as well as how to interact with it externally. Topics covered: Put items into the store Get items out of the store Within the store: Container to hold the items Retain the items in the container Store is data agnostic, meaning it doesn’t care what kind of data is stored in the container Items within the store have a unique identifier, i.e. so we can find and interact with each item in the store
Data Store – Planning the Requirements
Before we can build the data store, we need to understand what it is we need to build. In this lab, you’ll think through each of the requirements, working to define what makes a store a store, how to interact with it, what functionality is needed, and conceptually how to achieve it, and then what approaches you’ll employ in the series.
Planning the Refactor
As you were building this module, did you notice the redundancies within the view files? We are using separate view files that have virtually the same HTML structures to them. That’s not good. Why? Because if you need to make a change to the structure or one of the styling attributes, you have to remember to change it in three different places. That is an error waiting to happen. If you forget about one of them, then the change might get released and pushed out to your customers. That’s problematic. Instead, the better strategy is to combine the shortcode and […]
Module Architecture
Let’s think about the architecture for this module. How are we going to break up the code into sub-modules, feature sets, and sub-functionality? In this episode, you and I are walking through how to break this module down into its components and keep it centered on a single intent or purpose. How do you break things up and architect your plugins, frameworks, applications, etc.? Focus on the intent and purpose. List out the big buckets of what you’re going to build. Then group the like items together into a logical order where each one supports the single intent of the […]
Planning it Out
Let’s talk through what we are building together. Start with the Scope of Work, i.e. the big green box on the lab’s landing page. You’ll build the following: A custom post type called ‘faq’ A custom taxonomy for it to give us the grouping topics Add the page attributes to the custom post type to give us the ordering feature An archive page and custom loader We’ll use the SQL and $wpdb from the Advanced SQL lab. Then we’ll modify it for our needs. A shortcode with two different processes We’ll build it in that order, step-by-step. You are building […]
