Software Engineering in Web Development, Backend Services, and More
Articles, tips, and resources for WordPress-based development.
I joke with friends that Jetpack has become like the operating system of WordPress.
This isn’t to knock the good work the people at Jetpack are doing (because they are doing good work, are actively engaged in the community, and continue to iterate on the product).
But there are times where people don’t want to install Jetpack. Instead, they prefer to use third-party tools for whatever reasons. To each their own, right?
And there are quality Jetpack alternatives.
When it comes to talking about object-oriented programming (or OOP), you’re likely to hear about The Three Pillars of Object-Oriented Programming or The Four Pillars of Object-Oriented Programming.
Depending on your background, you may have already heard of them, know what they are, and don’t really need to dive into it too much. But if you have not, I believe understanding them is foundational to object-oriented programming.
We’ve covered the whole Analysis phase of Object-Oriented Programming:
With that said, let’s get into the design and implementation discussions. After all, this is what’s many people want to jump to anyway, isn’t it?
Before writing any code, I’d like to do two posts about the four points of object-oriented programming (because I’m one of those who subscribes to the idea that there are four).
In the previous post in this series, we talked about defining requirements (or a statement of work) and why it matters to have this.
Before we get into actually understanding – and writing – object-oriented code, there’s one more “business-related” topic to discuss: Terms and Conditions.
For many, it’s a bit of a dry topic, but if you’re looking to build solutions for someone else, do so from the ground-up, and do so properly, then it’s important to make sure you have all of the necessary pieces in place before doing so.
And once you’ve:
It’s time to make sure you have the terms under which you’re working.
A couple of weeks ago, I had the opportunity to chat with Matt Medeiros [once again] about various topics related to WordPress.
I’ve had the pleasure of knowing Matt for several years now, got a chance to hang with him at WordCamp US 2016, and continue to chat with him (when he’s not #medeirosing) both on podcasts and via other channels.
Yup – it’s one of those cases where you meet someone on Twitter, and they become friends. That does happen, you know.
Retweet if you've ever met someone face-to-face after previously only knowing them from Twitter.
— Eric Bailey (@EricVBailey) December 5, 2017
But I digress.
Instead, how about some more fun (or at least more interesting) things?
I don’t have many plugins available in the WordPress Plugin Repository anymore (and there are reasons for that), but I’ve been giving some thought to those plugins that I do have as well as the general level of code quality that goes into the first iteration of a plugin.
I mean, for some, plugins are merely small utilities that aim to do one thing and one thing well. Then, other plugins are much more advanced. I think these need a higher level of code quality to make them more maintainable.
But there’s one aspect of building plugins (or any software, really, but I’m specifically talking about WordPress plugins) that I find myself thinking about:
What level of plugin code quality of enough to ship the first version of a plugin?
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 ↑