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.
Some time ago, I began removing the HTML comment label from beneath the standard WordPress comment form (no, not the Jetpack-enabled form – the one that ships with a default WordPress theme).
Most of you are familiar with the form as it generally looks something like this:
HTML in Comments
Generally speaking I find that that block that usually sits between the textarea and the submit input to introduce complexity and likely cause more confusion than anything else.
One of the things that has been absolutely fantastic about the web is how much information we can publish and how much we can access it at any given time. I don’t know many who would disagree with that.
Even more so, for those who are interested in learning how to write software, there are various articles, podcasts, videos, tutorials, and so on all of which aim to teach a person the skills they need in order to actually get from not knowing how to write code, but knowing how to do so in a productive manner.
One of the downsides of this – and even more generally, open source – is that breeds this copy-and-paste mentality that completely undermines the very thing that it’s trying to teach: that is, how to write code.
One of the things that has become relatively common within themes that offer a lot of options is the use of tabbed navigation. That is, options that are related are logically grouped into tabs and then the user can navigate through each tab in order to select the options.
Whether or not this is a good thing for themes is outside the scope of this particular post; however, another place in which tabs may also be used is within the context of custom meta boxes.
That is, a custom meta box sits below the post editor and it offers several options or additions to the post meta data each of which is group together in their own tab.
Though I personally find this a bit more effective than using tabs of pages for screen options, that discussion is outside the scope of this post.
Regardless, there are ways to improve the ways in which custom meta box tabs are created such that they are organized in a more maintainable way, and each tab has its own view, partial, or template so that it’s easier to work with over time.
I know that there are different ways that people approach building WordPress themes and I’m not one to argue that there’s a single right way to do it. Sure, some ways are better than others, but that’s true of a lot of things.
Personally, I approach building themes, plugins, and so on as I would as if I was building some type of software. That has to do with my background. Similarly, someone who has a background in design and in front-end development will conceptualize what they are building in a different way.
Like I said, all of that’s fine (in fact, I think it’d be interested to see how different people view building themes, but I digress), but I do know that one common thing we always have to think about as it relates to updated our WordPress themes is the actual front-end design.
Specifically, does it make sense to completely change the design of a theme for a different version of the theme?
For some time now, one of the things that I’ve been considering writing about is the idea of refactoring.
Not necessarily in an incredibly specific sense – because each project is different – but in the sense of using some strategies that can help to take an existing project that’s running in a production server and slowly begin to refactor it so that its architecture changes but the functionality remains the same.
Anyone who’s worked in the software world knows just how nasty a codebase can get, and WordPress is no different. And I’m not talking about WordPress core – I’m talking about plugins, themes, apps, or whatever else it is that you may be building on top of WordPress.
For the most part, we start our projects with the idea that it’s going to have a great architecture, a pristine design, and that it’s going to basically be the best thing that we’ve ever worked with.
At some point, usually due to external factors, the thing devolves into a pile that we no longer want to touch, and we hope that it holds together to continue solving the problem at hand.
But it doesn’t have to be that way and even if the code you end up working with – be it your own, or someone else’s – has devolved into a big ball of mud, there’s still a strategy (probably multiple strategies) that you can use in order to refactor it into something far more elegant.
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 ↑