When developing code related to the WordPress heartbeat, it is frustrating to make your code changes and then wait for the next heartbeat to occur. You can trigger the WordPress heartbeat in the browser manually to eliminate this delay.
When two functions (or classes) have the same name, it triggers a fatal error in PHP. Namespaces are used to avoid these naming collisions.
While PHP namespaces allow you to refer to a function in file without using the fully qualified name, there is a catch when adding a WordPress hook or filter. The PHP __NAMESPACE__ magic constant can be helpful in this situation.
As a PHP programmer I’ve seen projects with a phpunit.xml file or a phpunit.xml.dist file (or even both, which is a mistake). These are configuration files for PHPUnit but why the two different file names? PHPUnit first tries to use phpunit.xml and if that file does not exist, then it tries to use phpunit.xml.dist instead. PHPUnit only uses one of these files, never both.
The “or” (||) operator and the “nullish coalescing operator” (??) can often be used in similar ways when reading a property from an object that may or may not exist. When dealing with strings you’re typically better off using “or” (||) and for numbers you’re typically better off using the “nullish coalescing operator” (??).
Semantic versioning (SemVer) is a standard for defining the version numbers. A version number consists of three numbers separated by periods (X.Y.Z). The type of change being introduced (e.g. a new feature or a change that breaks backwards compatibility) determines which numbers are incremented.
We can’t do a fast-forward merge when the most recent commit on the receiving branch does not appear in the branch we are merging in. One of our options in this situation is to create a merge commit when we merge in our branch.
While my mental model visualizes a Git branch as a stack of building blocks, in actuality a Git branch is a pointer to a single commit. Under the hood Git stores a text file for each branch and in the text file is a single line, which is the commit hash indicating the commit at the tip of that branch.
A Git commit, represented by a single building block in my Git mental model, is a frozen moment in time for your project (sometimes referred to as a snapshot). Along with this snapshot Git stores metadata about the commit (e.g. the author of the commit). Each commit has a unique identifier called the commit hash (a.k.a. SHA), a 40 character long alphanumeric string that is often abbreviated to just the first seven characters (e.g. “2b3a38b”).
We can’t do a fast-forward merge when the most recent commit on the receiving branch does not appear in the branch we are merging in. One of our options in this situation is to rebase the branch we want to merge in.