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.

The WordPress Widget Boilerplate: Refactoring, Part 5

If you’ve been following with the series up to this point, then you should be in a good position specifically for adding the Registry so that we have access to it throughout the plugin.

⚠️ Hey, Wait!

Thanks for your interest in this article! Note that it's available to members only. If you'd like to review this (and have access to all previous and future articles), check out the membership benefits.

The Autoloader

Now we’re beginning to use namespaces and use other classes. This means that we’re going to need to use autoloaders.

So before we go into refactoring the entire class as it stands right now, we’re going to take a slight detour into some of the features of Composer to see how it’s used to generate an autoloader (in addition to the things we’re already using it to handle the quality of our source code).