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.
The WordPress Widget Boilerplate: Refactoring, Part 8
The reason that I’m interested in primarily focusing on the administrative-facing side of the site first is that it allows us to:
- get a handle on how subscribers work,
- see how the code base will need to be organized,
- hardcode some information before working with serialization.
Once all of this is in place, we’ll be in a good position to turn our attention to more advanced things. Namely, we’ll be able to introduce subscribers for displaying information in the administration area and subscribers for sanitizing, serializing, retrieving, validating, and displaying data.
But first, let’s do the work necessary to set up a new class, configure the autoloader, and display content in the administrative area of the site.
Next, we’ll continue building out functionality for the administrative area of the widget. After that, we’ll turn our attention to the public-facing side of the widget as well as serialization functionality.
You should be able to see how things are beginning to take shape as we begin to separate the logic into its various components. If not, though, don’t worry – there’s plenty more to come.
And the final version of the Boilerplate will, of course, demonstrate all of the principles we’re building on throughout this series of posts.