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.
The WordPress Widget Boilerplate: Refactoring, Part 7
For those who are familiar with the WordPress Widgets API, then you likely know it hasn’t changed much over the past few years.
Furthermore, it really only consists of four functions (one of which is the constructor):
- The constructor is responsible for setting several properties on the widget, most commonly its name and the description of it.
- The widget function is responsible for rendering the content of the widget.
- The form function is responsible for displaying the form in the administration area of WordPress when working with the widget.
- The update function is responsible for updating the options that are saved in the database (or initialized and then saving the options that may not yet exist in the database).
The nice thing is that this particular approach is achieved by inheriting a functionality for the WP_Widget class.
The problem, though, is that it’s a lot of work for a single class to do.
Implementing Subscribers
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.
Finally, we’ll turn our attention to the code responsible for securing and serializing data (read: updating our widget), and then seeing what the final version of an updated boilerplate looks like.
In this post, though, the primary strategy that we’re employing is splitting up a child class so that it can still be used with other classes using interfaces and base classes that are already defined in the code base.
