Though the last post in this refactoring series wasn’t incredibly long, I do think it was a bit dense. That is, it required a fair amount of work to get the code in a place that we can more easily work with it.
But that’s just it: All the work we did should make it easier to move forward with the rest of the code we need to write.
And to make sure that we’re taking advantage of the work and the foundation we’ve laid thus far, we’re going to round out the series with a set of shorter, more focused articles that should take less time to read, implement, and understand what we’re doing with the code.
The WordPress Widget Boilerplate: Refactoring Part 9
Recall from the last post:
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.
And this sets us up for exactly where we’re headed in this particular post. Namely, we’re going to be writing an administrative front-end that allows us to:
- define a title for the widget,
- define text content for the widget,
- and toggle whether or not we want to show the title.
It’s not meant to be innovative nor is it meant to be the type of widget anyone else may want to sell. Instead, it’s meant to show how we can take what we have to create something similar to what we’ve already seen in WordPress and how we employ solid programming practices.
Sanitizing and Serializing
In the next post, we’ll look at what’s necessary to sanitize and serialize (or clean and save) the content of our widget.
We’ll also make sure we’re displaying the information in the administrative area after the information has been saved and retrieved.
Finally, the inheritance and class cohesion will continue to evolve but, for now, focus on what’s covered in this post and then we’ll continue in the next article.
