WordPress Widgets: Refactoring, Part 6 There's a problem we're facing with namespaces and autoloading and that's what we're going to review.

You should be well-versed in the refactoring we’re doing regarding the WordPress Widget Boilerplate. If not, I recommend catching up on the series thus far by:

As far as the code base goes, we’re in a good place right now. We’ve begun to refactor much of the code into smaller, more focused classes. And we’ve just set up a Registry so that we can begin working with instances of objects throughout the plugin without the need for too much coupling.

But there’s still a problem we’re facing and it deals with namespaces and autoloading. I’ve talked a bit about this a couple of years ago but not as it relates to Composer.

And that’s what we’re going to look at in this post.

Continue readingWordPress Widgets: Refactoring, Part 6 There’s a problem we’re facing with namespaces and autoloading and that’s what we’re going to review.

WordPress Widgets: Refactoring, Part 5 Once we have a Registry, we need to be able to access it throughout our plugin and we do that with custom hooks.

In the previous post, we created a Registry that is going to be used to store all of the various classes responsible for giving our widget its functionality.

To do this, there’s going to be a variety of other classes introduced, but before going there, we need to add the Registry to the plugin’s bootstrap (let alone create a bootstrap for the plugin).

Specifically, here’s where we left off:

As mentioned earlier in the post, we need to add this to the bootstrap of the plugin. To do this, though, we need to define our own filter so that we can easily pass the registry around the rest of the plugin (when the time comes to do that).

So in this post, we’re going to focus on doing exactly that.

Continue readingWordPress Widgets: Refactoring, Part 5 Once we have a Registry, we need to be able to access it throughout our plugin and we do that with custom hooks.

WordPress Widgets: Refactoring, Part 4 Keeping our objects decoupled from one another increases the quality of our code. To start doing so, we can use a Registry.

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.

WordPress Widgets: Refactoring, Part 4

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 readingWordPress Widgets: Refactoring, Part 4 Keeping our objects decoupled from one another increases the quality of our code. To start doing so, we can use a Registry.

WordPress Widgets: Refactoring, Part 3 Arguably, the biggest problem with the Boilerplate is that everything is encapsulated within a single class. So let's change that with abstract classes.

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.

WordPress Widget Boilerplate: The Develop Branch

Thus far, we’ve:

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 readingWordPress Widgets: Refactoring, Part 3 Arguably, the biggest problem with the Boilerplate is that everything is encapsulated within a single class. So let’s change that with abstract classes.

WordPress Widgets: Refactoring, Part 2 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.

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.

Screen Capture on 2018-11-20 at 12-50-27.gif

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 readingWordPress Widgets: Refactoring, Part 2 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.