We’re done with both requirements documents. It’s time to push the branch to GitHub. In this episode, you’ll: Push the branch to GitHub Create a Pull Request (PR) Change the master repo to your GitHub account instead of the original on Know the Code Walk through the PR GUI Merge it into the master branch Delete the requirements branch Pull the updated master branch down to your machine to sync you up with GitHub
Everything is installed on your local machine. Let’s walk through the plugin’s code together. You’ll also commit the updated composer.lockfile and fix the root namespace too. Then you’ll push those changes to your repo on GitHub.
If you are using Local by Flywheel, you need to install and setup PHPUnit before you can get to work. SSH into your project’s server Download this script Then you’ll follow the instructions to finish the installation and setup.
You need a copy of the starter plugin. In this episode, you’ll Fork the plugin to your personal GitHub account Clone your copy of the plugin into your local project, i.e. onto your computer Test out that it’s wired to GitHub with git statusand git remote -v At this point, make sure you have the git aliases setup on your machine. If you haven’t already done Git Productive lab, you can grab the aliases for your .gitconfig file in this gist.
Before we start the project, you need to setup the project’s environment. You’ll use this environment and workflow throughout the series to plan, build, test, and validate the data store. You’ll fork the starter plugin, clone it to your local machine, run the starter test suite, and walk through the plugin’s architecture and setup.
There are times when you want to empty all of the items from the Data Store. For example: When testing, you want to clean up after a test case. Another example is when the data has been used and is no longer needed. In this case, you are releasing the memory for better performance, i.e. optimization.
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.
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.
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.
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.