Tag: WordPress Widgets (Page 2 of 4)

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 reading

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:

• hooks,
• a Registry,
• and Subscribers.

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

Continue reading

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:

• reading the previous post,
• or reading the entire series up to this point,
• and looking at the development branch of the project on GitHub.

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 reading

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 reading

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