Software Engineering in WordPress, PHP, and Backend Development
As I mentioned in yesterday’s post, I’m going to be turning off pingbacks for the public-facing side of this blog for a number of reasons the least of which is not to help make it easier for others to participate in comments.
In order to do that, I’ve written a small plugin that helps makes this really easy to do:
Sound simple, right? Here’s more information.
One of the features of WordPress that used to be significantly more popular is that of trackbacks and pings (or more commonly referred to as pingbacks). In short, it’s a way for those who run a blog to know when someone else has linked to one of their articles.
It’s kind of a flattering thing, isn’t it? I mean, someone is writing a post and then linking their content to yours? Then again, sometimes they could just be responding to something you’ve said in a negative way. That’s not always the most flattering thing, I guess, but it fosters conversation nonetheless.
Pingbacks are the ping pong of blogging. Or something like thing.
Regardless, I’ve seen some people question the purpose of pingbacks, question whether or not they should be enabled or disabled, and question whether or not they actually help readers when skimming through the content.
Though I personally don’t have any kind of evidence from any kind of study to back up any of those points above, I have decided to turn pingbacks off on the public-facing aspect of my site in the coming days.
One of the best parts about being someone who uses WordPress on a daily basis both for personal use and in doing work for others is the ability to create solutions to problems that you encounter throughout your day-to-day.
Obviously, some problems are more complex than others and require more elaborate solutions, whereas others are easier problems that still may call for a simpler solution, but a solution nonetheless.
Case in point: In a few recent projects, I’ve needed to integrate an image widget that allows users to easily upload images into sidebars and/or widgetized areas of their blog. The challenge, however, is that there are multiple ways to go about doing this.
So my first take at implementing a solution for this particular problem comes in the form of the Pressware Image Widget for WordPress.
It’s no secret that one of the things that I love most about the most recent versions of WordPress is the Theme Customizer (which is soon to be called the Customizer). I’ve talked about it in a number of different articles, some of which include:
Further, I’ve been clear in stating that I think that as much as I like the Customizer, we’re beginning to see the same problems, but in a different place.
Simply put, I think that we’re disrespecting our customers and damaging the WordPress customizer.
And over the past few weeks, I’ve seen this manifesting itself more and more through various themes I’ve seen, various screenshots I’ve seen, and various other discussions I’ve seen.
Granted, I’m not really one in a position to say what a person opts to do with their own projects, and I’m not particularly interested in getting up on a soapbox (but this is probably going to read like that, so there’s that, I guess) and telling everyone how or why to do something, but I do have strong opinions on the WordPress philosophy and how it directly contributes to developing themes.
As it stands now right now, I think that we’re doing a terrible job of respecting the WordPress philosophy, putting it to work for us, creating happy customers, and leveraging the WordPress customizer for the betterment of the WordPress economy.
One of the things that’s always been somewhat of a point of pain in both theme and plugin development is how to handle JavaScript in WordPress.
By this, I’m not talking about third-party dependencies such as jQuery, FitVids, or whatever libraries Bootstrap, Foundation, or what’s contained within the frontend framework you opt to use when building your theme – instead, I’m talking specifically about code that we write in order to get things done within the context of our work.
When it comes to procedural programming in WordPress – think working in functions.php – it’s expected that we’re going to be naming our functions with a unique prefix in order to prevent conflicts with other functions that may exist within plugins, third-party libraries, or even in WordPress itself.
For anyone who is just getting started in working in WordPress, this can be a hard lesson learned depending on if you’re one of the “read-the-documentation-first” type of people or not, but the thing is that the global nature of PHP mixed with the wide array of functions included in WordPress, PHP, and third-party code can lead to naming collisions that will either break the overall application or cause erratic behavior.
Most likely the former, but whatever.
But look at that: I spent the entire first part of this article talking specifically about naming PHP functions – but this is exactly the point I’m trying to make: We spend a lot of time talking about doing this in PHP, but not a lot of time talking about doing it in JavaScript.
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 ↑