As with many other blogs, shops, products, and services during this time of year, I’m offering discounted memberships on this blog from Black Friday thru Cyber Monday.
What does this really get you, though?
Software Engineering in WordPress, PHP, and Backend Development
As with many other blogs, shops, products, and services during this time of year, I’m offering discounted memberships on this blog from Black Friday thru Cyber Monday.
What does this really get you, though?
As is the same with every single year (well, save for last year when I forgot to write a post – or simply neglected to do so 🤷🏻♂️), we’re celebrating Thanksgiving in the United States.
I dig this time of year and continue to do so the more our family grows, and the more time we’re able to spend together.
The purpose of this series is to start doing a deeper dive into working with object-oriented programming in the context of WordPress.
And since the WordPress Widgets API is one of the APIs that does use object-oriented practices, it’s a logical place to start. Further, it will give us some foundational techniques that we can use to apply to future work as we see how to build more object-oriented projects on WordPress in future series.
So far, we’ve covered the following:
If you’re not caught up, now’s a great time to do so. And if you have, then you’ll recall from the last post, we ended with the following note:
That is, we’ll revisit the WordPress Widget Boilerplate and I’m going to be refactoring it in its current state to adopt more modern PHP standards.
To begin updating the WordPress Widget Boilerplate to follow said standards, we need to do a few things:
And that’s what we’re going to start doing with this post.
Back in 2011, I was doing a lot of reading on working with legacy code, code quality, and refactoring.
There’s a quote by Martin Fowler (who literally wrote the book on refactoring) attributed to Uncle Bob that’s stuck with me – and I’m sure many, many programmers – ever since:
always leave the code behind in a better state than you found it
The thing about this particular idea is that I think it might sound a bit more idealistic until you really start to try to practice it in everything that you do.
That is, if you take it at face value it sounds like anytime you need to work on a codebase, then you need to leave the entire codebase better than when you found it. But the more I’ve tried to apply this rule in my day-to-day work, the more practical, the cleaner, and the more maintainable WordPress-specific code has become.
So when it comes to refactoring WordPress-based code, what does that look like?
Earlier this year, I talked about launching a project to help improve the blogging process in WordPress aptly named Blogging Plugins.
I’m going to be sending out a survey to potential users very, very soon and I need you to be on the mailing list even if you’re the least bit interested.
To join the list, you can do so on the homepage. But if you want more information, please read on!
At the time of this writing, we’re in the middle of a lot of conversations around the Classic Editor, Gutenberg, and so on.
This has nothing to do with that. If you’re coming into this reading with that mentality, relax and set it aside 🙂. This has nothing to do with what I’m going to share.
Now back to the project.
I’ll keep this short: Pressware had a busy year (which is not a bad thing). I wasn’t able to devote the time I thought I was going to have to this project.
But I’ve now reorganized by schedule, developed a few foundational libraries for the sake of reuse and am planning – and have already started, really – on building out plugins.
That’s not enough, though, and – if you’re reading – this is where I need your help.
© 2025 Tom McFarlin
Theme by Anders Noren — Up ↑