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.
The WordPress Widget Boilerplate: Refactoring, Part 4
One of the problems that still exist in the code as it stands right now is that the widget’s constructor is registering functions and this isn’t a good thing.
The purpose of a constructor is to set the values of properties of the class, not to implement any type of logic. This is for a few reasons:
Before The Bootstrap, Though
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).
Before we do that, though, it’s important to make sure you’ve got a good handle on the Registry we’ve just created, that it fits into the plugin and that you’re tracking with the develop branch that we have thus far.
