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.
When organizing assets in a project, it’s common to see source and distribution directories. Sometimes these are organized a little different, but they generally serve the same purpose.
Overtime, I’ve moved from one form of organization to another. And I’ve found it to be easier to handle during deployment and maintenance of a project after release.
So here’s a rundown of how I used to organize my files and how I’m currently doing so now.
For many of us, we spend our time heads down on projects trying to deliver solutions for a customers. That’s a Good Thing™, as far as I’m concerned.
But every now and then, I think it’s also a Good Thing™ to take stock of where we – as a development community are – where we’re headed, and the things that we’re able to observe about ourselves.
We need to observe where we are (and from where we’ve come).
Now and again, I’ll write about my own opinions about WordPress (the software, the community, the economy, etc.). I don’t always have a direct point, though.
Sometimes it’s just a smattering of thoughts about what I’ve seen. You know, like a digression. And that’s what this post has shaped up to be.
Years ago, I wrote a series of posts for Envato walking readers through how to use Ajax in WordPress.
Then, not long ago, I provided an updated walkthrough of how to do so with better practices (thanks to @gmazzap for the code review on that one).
One purpose of this blog is to provide articles for others who are getting started in WordPress development. That is, I want to share the things I’ve learned to help shortcut others’ learning.
Sometimes, this requires updating old content. Or it requires providing new ways of doing things already discussed.
Case in point: Using Ajax in WordPress.
To me, one of the most interesting aspects of open source culture is the variations in open source philosophy we all have.
By that, I mean though many of us appreciate what open source has done, we have varying degrees on how much we use it. For example, some people use only open source software. On the other side of the spectrum, some people never use open source software.
Then, as expected, there are a lot of things that sit between these two points. You know: The proverbial gray area.
As of last week, an interest article has been making the rounds about Slack and FOSS projects. I’ll talk about it more in a moment.
But first, since I’ve never written about my own perspective on open source, I thought I might as well try it.
When The Customizer (once called The Theme Customizer) became part of WordPress, we saw a resurgence in the Theme Modification API.
At one point in WordPress history, the get_theme_mod and set_theme_mod was how we handled theme modifications (hence the function names). Then, we began to use the options table as a way to manage the various settings for our plugins.
And then we began to use the options table as an easy to way to store settings for our themes. It was like we moved the Theme Modification API to the backseat and pushed forward with options.
Should we have done that (or does it even matter)? And what’s the difference in these APIs, anyway? Why do we still have both of them, which is best to use and when?
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 ↑