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