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.
Source code – let alone WordPress code comments – is one of those things that often divide developers:
In my latest series on Envato, I discuss a case for WordPress code comments on both the server-side and the client side.
One of the things that makes developing for WordPress so fun is the nature of its extensibility through plugins. When it comes to WordPress plugin programming, there are actually two ways that you can write your plugins:
In the lastest series running on Envato, Stephen Harris and I provide an in-depth discussion on both of these strategies.
Ever since smartphones have become mainstream, there are apps for almost everything. Prior to this revolution (if that’s what you’d like to call it), we had phones that a had a few [weak] tools on them, but most of our work was done on a computer.
And the computer had software, or computer programs, or applications – whatever you’d like to call them – and that’s how we got work done.
This is likely going to make me sound a bit weird, but for the past few months I’ve been periodically asking people how they define an app. Of course, I don’t ask it like that. Instead, it’s goes something more like:
So, hey, what’s an app?
And nine times out of 10, I end up getting the same response:
A little program (or icon, even!) on a phone.
Some people have responded that it’s also something on their tablet. Fair enough.
I definitely attribute this change in vernacular to Apple. After all, they’re the one’s who started the App Store with the vision that people could create an app for anything.
But what is an app?
From a problem-solving standpoint – not even a computing standpoint – I have this idea that almost everything is an app.
For anyone that’s been doing software development for any reasonable length of time – especially for web applications – then you’re likely familiar with Local (or Development), Staging (or Test), and the Production environments.
If not:
Most developers who are in the business or closely working with their client follow this particular setup.
In the past couple of months, there have been a few times when a single production rollout has fallen short and ended up either revealing bugs that were not caught in Staging or that did not hold up under Production-level loads.
As frustrating as that can be, I’ve ended up using a sort of two-phase Production deployment plan to help mitigate this.
Ah, the stock photo of Tech Support for the entire Internet!
One of the challenges of providing solutions built on top of WordPress is handling expectations of support and documentation. I’m not talking about running a support forum or writing elaborate API documentation.
Instead, I’m talking about providing instructions for how users can manage their site, application, or plugin once you’ve completed work on the project.
Over the past couple of years, there have been a few things that I’ve tried. I’m definitely curious to hear you guys’ thoughts on what you’ve done and what you’ve found to be successful, but first, here’s how I’ve historically handled WordPress support after a project handoff.
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 ↑
