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.
To do this, though, assumes you know how to define your filters. In WordPress, we use actions and filters all the time.
The thing about these hooks is that they are already defined, though. So how do we define our filter?
Let’s take a look at doing exactly that.
1. Defining Our Filter
First, we need to understand a few concepts:
- what a filter is,
- how to add a filter,
- how to introduce our registry into the filter
- how to retrieve the class from the filter.
Luckily, all of the above is easy to explain.
What is a Filter?
Simply put, hooks allow us to call into WordPress at specific times during the program’s execution. Actions are usually reserved for behavior; Filters are reserved for data.
Furthermore, filters allow us to work with specific data in the application – it can be pre-existing data or even new data. And in our case, it’s going to be the Registry class that contains references to other data.
Adding a Filter
Adding a filter is easy. It has three parts to it:
- calling add_filter,
- defining a unique identifier for the filter,
- passing information into the filter than can be returned whenever its called.
For us, I’m going to identify our registry as the wpWidgetRegistry filter. Note, however, that it’s important you choose a unique name for your implementation because if you don’t, you could end up with collisions with other data if another plugin uses the same identified.
Anyway, adding a filter performs a simple task:
Hook a function or method to a specific filter action.
So this means that we need to define a method with our ID. Because of the nature of PHP, we don’t need to use a separate function.
Instead, we can use an anonymous function.
Anonymous functions, also known as closures, allow the creation of functions which have no specified name. They are most useful as the value of callback parameters, but they have many other uses.
The anonymous function that we’re going to define will accept a reference to the plugin as an argument and then return it whenever the filter is called (which will be shown later in this article).
Passing Information to Our Filter
Now that we have all of that covered, we can go through the process of creating an instance of our Registry, defining a filter, and then adding the registry, so it’s accessible throughout the application.
So within the main plugin file, that is the wordpress-widget-boilerplate.php file, we add the following lines of code:
The above declares the namespace in which the Registry resides. Then we add the following block of code below the autoloader:
Note that when you aim to activate the plugin, it won’t activate and will throw an error. This is because of the lack of an autoloader which is going to be discussed in the next post.
2. Retrieving Our Registry
Since the registry is defined in the plugin’s bootstrap and is done so through the use of a filter, we can access the registry anywhere in our plugin by calling our custom filter.
For example, let’s say that we’re in another class and we need to gain a reference to the registry. To do this, we can make this call:
And that’s it. Easy, right? As long as everything has been properly added to the registry – which is going to be covered soon – then we’ll be able to access all of them through the unique identifiers we used in the previous post.
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).