TL;DR: The WP Plugin Scaffold repository contains a a very basic set of files that are needed to spin up a Composer-based WordPress Plugin.
Over the years, I’ve written or contributed to a number of different projects that have been aimed at making WordPress plugin development easier. At this point, there are a variety of ways people are creating WordPress plugins such that there isn’t really a way to create a boilerplate to capture all of them.
So I’m not aiming to do that.
But over the last few months (or maybe a year?), I’ve been working with the same structure for creating plugins. It normally grows into something larger based on if I’m taking an object-oriented approach or a procedural approach. It also changes based on how large the plugin is, what its purpose is, who is going to use it, or how it’s going to be used.
To that end, I’ve ended up with a very basic set of files that every project incorporates regardless of the size.
As such, I thought I’d share it.
On the whole, writing a post about other posts – aside being very meta – isn’t something I’m fond of doing.
But here I am.
At the beginning of this year, I started working on a podcast backup utility called Backcast and I’ve been documenting the project throughout the year in a series of posts.
But given that I was making steady progress on this and given that it’s something I want to continue working on since it’s something I have use for, it seemed worth commenting on it if for no other reason than posterity.
TL;DR: I’m tired of writing code without consistent standards (I often work on code that changes between WordPress or PSR2) so this is how I installed PHP Coding Standards via Composer and a few extra extensions for the project. This also details how to automatically format the code on save.
TL;DR: The private podcast account is set up but not yet recorded; I’m looking to do that sooner rather than later. I’m looking to possibly abandon exclusive Overcast support which I’ll briefly talk about. This article walks through the process of defining the conditions for unit testing and how I’ve decided to go about writing the first set of unit tests.
TL;DR: In this post, I cover PHPUnit, PHP,
phpunit.xml, unit testing, and macOS and how to get them all to work together despite what ships with macOS.
In the initial draft of this post, I wrote about how I was going to start writing unit tests for small pieces of functionality as well as show exactly what functionality I was writing (and the why behind it).
But this took a weird turn that that led me on a long digression into three things:
- PHPUnit 9,
- the version of PHP that ships with macOS,
- And how to get them to work together nicely.
So rather than try to cover all of that in a single post, I thought it better to talk about PHPUnit, PHP,
phpunit.xml, and macOS in a single post, then get back to to the practical work of building the project.