Software Engineering in WordPress, PHP, and Backend Development
Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.
Writing good changelogs seems to be one of those things that many of us talk about doing talk about wanting to see, but often don’t do it.
Or maybe it’s better to say that we often complain about the types of changelogs that we see, but don’t offer any advice of updates them ourselves.
And maybe that’s not the right thing to say. I mean, we do offer advice on how to update them. But does that stop us from writing better changelogs ourselves?
About four years ago, I shared a post about WP-CLI. It wasn’t exactly a new project at the time, but it was far less developed than it is now.
The WP-CLI Homepage
As I mentioned in yesterday’s post, one of the things that we’re doing with is making sure that all of our work is unit tested from the initial version.
And when it comes to unit testing in PHP, many of us are familiar with PHPUnit; however, when it comes to unit testing plugins that are integrated with WordPress, it helps to have a test environment set up.
Sure, it’s possible to set aside a test database, test content, and then defined mock objects based on interfaces (and I’m not here to dissuade anyone from doing that). But WP-CLI offers a much easier way to go about doing just that in a more automated manner.
But first, it’s important to make sure that it’s correctly installed on your system.
We do a good job of evangelizing the different tools, environments, and ways to tackle problems in our space (that is, within WordPress development), but I often wonder how well we do for actually documenting our practices, procedures, and so on for others.
Sure, some companies open source their practices, and that’s great, but does every company? And should they?
Sometimes, I think people believe that if a company bases itself on open source, then they should have everything out in the open:
I don’t agree, but I do think there’s something to be said for documenting your practices within your team as this benefits both you, your teammates, and people you may end up bringing on to a project or on to your team for future work.
One of the nicest APIs that the application offers is the WordPress Metadata API. It’s through this API that we’re able to take ideas such as posts, users, comments, terms, and more and store richer information that just the standard set of information.
Sure, there’s a lot to consider when taking advantages of these additional columns or fields as it relates to these concepts. But if you’re a beginner or someone who’s just starting to get deeper into the WordPress API, then I can’t recommend learning these APIs enough.
In two recent series for Envato, I cover these concepts in-depth.
Lately, I’ve been trying to write shorter, more focused on articles on particular topics, but there are times in which a longer article is warranted: Case in point: Using PHP and Composer in MAMP.
Before you get started reading this article, I’m assuming you have a couple of things:
It’s not that any of this is intimidating. I mean, if you’re completely inexperienced, there may be a bit of a learning curve, but I’m going to do what I can to break this down for you regardless of the level of experience you have.
Ultimately, the goal is to make it easier for you to write more modular code using third-party dependencies and with keeping things well-organized on your system and in your projects.
Kinsta offers premium managed WordPress hosting for everyone, small or large. Powered by Google Platform and strengthened by Cloudflare, they take performance to the next level. All hosting plans include 24/7/365 support from their team of WordPress engineers. Get started with a free migration today.
© 2026 Tom McFarlin
Theme by Anders Noren — Up ↑