WordPress Widgets: Refactoring, Part 8 We'll start breaking apart the various components that go into making up WordPress widgets starting with the administrative area.

When it comes to refactoring the WordPress Widget Boilerplate, we’ve done a lot of work to bring the code base up to more object-oriented standard. Further, we’ve introduced a variety of other tools that allow us to bring our code up to more modern standards

Now that we’ve spent time doing that, it’s time to jump back into the code and begin refactoring it in such a way that allows for the use of abstract classes and subscribers (that work as part of the event-driven design pattern).

At the end of the previous post, I wrote:

In the upcoming posts, we’re going to look at how we can implement subscribers for the public-facing side of the site (that is, where the widget content is displayed). And we’ll do the same for the administration area of the site.

So in this post, we’re going to do exactly that. Specifically, we’re going to start with working on a subscriber for the widget and then getting the base widget to display on the administrative side of the site first.

Continue readingWordPress Widgets: Refactoring, Part 8 We’ll start breaking apart the various components that go into making up WordPress widgets starting with the administrative area.

WordPress Widgets: Refactoring, Part 7 The problem with WP_Widget is that it's a lot of work for a single class to do.

In the last few posts, we’ve done a lot of work to bring the code up to the point of refactoring that’s going to be covered in this article.

Specifically, we’ve covered:

All of these are going to play a role in what we’re going to do today.

Continue readingWordPress Widgets: Refactoring, Part 7 The problem with WP_Widget is that it’s a lot of work for a single class to do.

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.