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.
A lot of the posts I write include command-line interface (CLI) commands to type in. I’ve found over time there are things I can do to improve how these commands are communicated.
The short answer is, “yes”. You should use your .gitignore file to ignore the .env file.
In most operating systems by default, files that start with a period (.) are hidden. When setting up my .gitignore file, I like to ignore all these hidden files (with a few exceptions).
This is my general starter .gitignore file for projects. I have a separate .gitignore for WordPress websites.
I’m a big fan of Git and I’ve worked with lost of developers in growing their Git skills. Often developers learning Git, start by learning how to write a “good” commit message. While writing “good” commit messages is an important skill, in my opinion it is the wrong place to start.
These are the rules I follow when writing Git commit messages. I’ve found these serve me well and are compatible with most projects I work on (if a project has a specific set of rules for writing Git commit messages, those would override any rules I’ve outlined here).