Over the past few years, I’ve spent a significant amount of time writing about a lot of things on how to achieve certain things in WordPress. And I don’t regret it (after all, it’s my career and it’s even the subtitle and focus of this blog).
But one of the things that I’ve opted to neglect is a focus more on topics that interest me such as object-oriented analysis, programming, design, and implementation. (And, of course, doing so within the context of WordPress.)
And sure, there are some articles where I’ve touched on it but I recently took a week off of pretty much everything except my [growing] family and during that time, I took stock of a variety of things.
One of those things included this particular site, its content, and the general focus of my career.
A few months ago, I had the pleasure of writing the forward to Cal Evans book Using the WordPress REST API. Shortly thereafter, Cal asked if I’d join him on his podcast, Voices of the elePHPant, to talk a bit about software development in the context of WordPress.
And given that that’s what I’ve spent the majority of my career doing, it made sense to participate.
This not only gave me a chance to catch up with Cal “face-to-face” but also to share a bit about what it’s like working in this particular corner of the PHP community and in the WordPress economy.
It’s one thing to be using PHP CodeSniffer manually but if you’re using a utility such as GrumPHP to check your work before committing it to the repository, then you’re likely going to want to use the version that you’re installing with your project.
This assumes that:
You are installing PHP CodeSniffer local to your project,
You want to install a specific set of coding standards to run against your code.
Remember, this is also done in the context of wanting to run automated scripts during the commit process and in a local environment (versus a global setting) with Composer.
cURL is a very popular PHP library that I’ve referenced in several posts other posts (1 and 2, for example). And it’s one that I think should be reviewed, explored, and possibly used by anyone working in PHP (yes, even those working in WordPress).
But because of the native WordPress APIs, we do have a level of abstraction that allows us to achieve much of the same functionality (if not the same functionality).