Software Engineering in Web Development, Backend Services, and More
Comments on this post have been closed. Please leave your comments on the original article!
Earlier this week, I had the pleasure of being featured on the ManageWP blog with some other fantastic writers, developers, designers, and bloggers all of whom opted to share their favorite WordPress shortcuts, tools, and tricks for getting their work done faster.
Overall, there were 28 people who were featured all of whom had some great things to say.
In a recent project, I’ve been working with large groups of input elements, and the course of action that’s taken depends on the type of element that raises the event.
Since so much of the project uses jQuery, I opted to write an extremely simple plugin that makes it easy to get an input’s type by calling a function on said element.
A few months ago, I did a series of articles on Design Patterns in WordPress that was meant to provide an introduction to object-oriented design patterns, and how they can be used when developing projects on top of WordPress.
When it comes to working with WordPress, code is normally written one of two ways:
For procedural programming, think of `functions.php` in theme development, and for object-oriented think of plugins. This isn’t to say that procedural programming isn’t used in plugins – it often is (case in point: Markdown Code For WordPress) – but so are object-oriented techniques (see the WordPress Plugin Boilerplate).
In short, decide patterns exist for a reason: They are proven solutions to common problems that appear in software development.
Yes, they may have to be tweaked a bit for a given situation, but the definition, structure, and so on remains the same. The thing is, I don’t often see many design patterns used throughout WordPress product development.
To be clear, I’m not talking about WordPress core, I’m talking about products built on top of WordPress. Perhaps I’ve just not done enough digging or paid enough attention to some of the work that’s out there, but I think if we – as developers – spent time working on implementing design patterns in our work, projects could have much more longevity rather than devolving into spaghetti code that’s so often found in WordPress work.
Last week, I had an interesting request for my Comment Images For WordPress plugin:
I wanted to make the default DISABLE so I could turn it ON on the ones I need it, instead of having to go through 200 posts and turn it OFF on 190 posts, that’s all. But if that’s not possible I understand.
Truth be told, this is a scenario that I’ve never thought of, but if you’re someone with a blog who has hundreds (or even thousands) of posts, then being able to disable or enable the feature across the board makes sense.
With the recent release of WordPress 3.6 and its built-in support for audio files, I’m opting to to halt development on WP Audio Player for WordPress plugin.
Here’s the thing: This has nothing to do with WordPress folding something into core that was once available via plugins and putting a plugin “out of business.”
Mostly, it has to do with my personal preferences and opinion behind the core libraries used in WordPress 3.6.
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 ↑
