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:
- WordPress Widgets: An Object-Oriented Approach. The Widgets API provides a solid litmus test and example of how to get started with object-oriented programming in WordPress.
- WordPress Widgets: How to Detect Object-Oriented Programming. The goal is to arm you with everything you need to detect object-oriented practices.
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:
- create a branch from the existing boilerplate,
- install code quality tools,
- ensure our IDE is properly set up,
- and begin refactoring the code to said standards.
And that’s what we’re going to start doing with this post.
Starting with Standards
If you’ve been a member of this site for some time, then you know that I prefer to use Visual Studio Code. If not, I have an entire set of articles devoted to how I use it (and thus how we’ll be using it throughout this series of posts).
And if you’re interested in coverage regarding coding standards, debugging, IDEs, development environments, and so on, check out The Independent WordPress Developer.
However, I’m assuming that if you’re reading this then you’ve read through the material above or you’re comfortable going through all of the material above.
With that said, let’s get started.
So where’s the object-oriented nature of this coming from? Up to this point, we’ve been talking about using the Widgets API as an object-oriented model for writing object-oriented code in WordPress.
Some of what we’ve done thus far has been exactly that (by talking through its principles, seeing how its laid out, and more).
But as I mentioned at the start of this post, laying code quality tools first provides us with a foundation we can use as we refactor the boilerplate (which we clearly need to do given the amount of red shown by GrumPHP).
And that’s where we’ll start in the next post in this series.