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.
Last week, I had the pleasure of speaking to my local WordPress Developer Meetup group on an introduction to WordPress theme development.
Ultimately, the goal was to give a foundational talk so that more advanced topics in theme development could be shared throughout the rest of the year all of which I’d love to continue to share here, should it pan out. Continue reading
When it comes to writing plugins – specifically those that are object-oriented in nature – many of us do so because we’re obviously fans of writing object-oriented code.
Personally, I’m a fan of it because it helps to separate the responsibilities and concerns of a requirement into its own logical unit.
Sure, this can be done with several function files as well, but I come from an object-oriented background, so when I approach a problem, I automatically begin thinking in terms of classes and their relationship to one another.
And I know that other developers do the same.
The thing is, I think some of us – myself included – have gotten lazy or we only half-bake our object-oriented-based plugins. That is to say that we may be using classes in writing our plugins, but we don’t do such a good job of taking advantage of other object-oriented principles and features.
Last week, a fellow WordPress developer and I were having a conversation about a particular feature that he’s been contracted to implement for an existing site.
In short, he was trying to decide between introducing the new feature in the form of a child theme or in the form of a plugin.
It’s a question that I see raised more often than not, but I think there’s a series of questions that we can ask ourselves before jumping into writing any code.
Generally, it has to do with the true definition of a theme and the true definition of a plugin. Of course, there’s room for deliberation, but here’s how I normally see it.
When it comes to writing, releasing, and maintaining WordPress plugins is figuring out how to actually support your work once it’s released.
After all, the majority of work on software is maintaining the codebase and responding from all of the feedback given by users or customers.
In my latest article on Envato, I talk specifically about strategies for supporting WordPress Plugins – I lay out some of the problems that currently exist, and also invite readers to share their experience, concerns, and suggestions with what’s available today.
Earlier this week, I shared a post on You Can’t Ask Users To Upgrade WordPress To Fix Their Problems. In the post, I shared a few reasons as to why it’s dangerous to expect and/or trust your customers to upgrade WordPress.
You can read the full article for my reasons why, but Mike brought up an interesting statement in the comment feed that got me thinking about the ethics of our responsibilities a developers for building projects for clients.
Though ethics are subjective and that you’ll rarely hear me talk about them on this particular blog, I think that there is room for discussion as to what constitutes the ethics of programmers in the case of building, releasing, and maintaing software for others, and, in this case, within the WordPress space.
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.
If you are looking for WordPress guides and unbiased reviews, I recommend checking out WPKube. They also have an exclusive deals section.
© 2025 Tom McFarlin
Theme by Anders Noren — Up ↑
