Tag: Object-Oriented Programming in WordPress (Page 3 of 6)

We’ve implemented a significant amount of changes to the WordPress Widget Boilerplate. If you’ve not been following along, I recommend starting at the beginning of the series and catching up.

If, however, you’ve been following along and you’re also running some of the code quality tools that examine the state of the project, then you’re going to notice a handful of errors in the console.

Normally, this is the point where I recommend paying attention to what it shares and then fixing whatever it reports, but we’re not there yet.

For example, some of the errors that our tools are showing right now are based on the fact that we have unused variables. Of course, that’s the case, though, because we haven’t started building a widget.

But there are still a few concrete classes we need to implement.

Continue reading

In terms of updating the WordPress Widget Boilerplate (all of which is tracked in the develop branch), we’ve come a long way in terms of refactoring how it’s organized.

Thus far, we’ve:

• looked at how the WordPress Widget API provides an example of object-oriented programming,
• how we can use this API to determine object-oriented programming in other areas of WordPress,
• installed tools to help us evaluate the quality of the code,
• found errors that currently exist in the code in terms of modern programming standards,
• and began re-organizing the code base so that it fits with more modern practices.

Now we’re ready to start refactoring this code in a much more object-oriented manner.

So if you’ve yet to catch up with the previous posts (any of them, really), I recommend doing so because it’s going to take a little while to bring this up to date. There’s a lot of code to write an explain.

Let’s get started.

Continue reading

After all of the preliminary content, we are finally at a place where we are ready to begin resolving the coding standard problems thrown by our IDE and by our code quality tools.

In doing this, I’m going to be breaking down the content into two posts:

• the first post is going to focus solely on refactoring the existing code,
• in the next post, we’re going to look at refactoring the structure of the plugin to enhance the organization and architecture.

For now, though, let’s take a look at the errors the code sniffer is throwing and see if we can’t bring it up to more modern standards.

Continue reading

The last post included a lot of information on setting up code quality tools in your WordPress development environment, but they are necessary if we are going to be doing a lot of refactoring.

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).

Honestly, I see these as necessary if you’re going to be doing any type of development hence the need to show how to set them up.

Regardless, the previous post shows just how much work we have cut out for us, right?

Now we’re going to start with refactoring the WordPress Widget Boilerplate.

This will not only improve the code quality but also walk us through some object-oriented principles that we can apply when building our widgets and we can apply in future WordPress development efforts.

Continue reading

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:

1. 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.
2. 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:

1. create a branch from the existing boilerplate,
2. install code quality tools,
3. ensure our IDE is properly set up,
4. and begin refactoring the code to said standards.

And that’s what we’re going to start doing with this post.

Continue reading