In the previous post, we walked through a lot of refactoring that separated concerns into their own classes.
Ultimately, this helps show how we can maintain a high level of cohesion while not only working with classes in WordPress but doing so alongside pre-existing APIs.
Because the last few posts on refactoring the code base have been so long, the current set of posts are focused on small, incremental changes and thus shorter, more focused posts.
As mentioned in the previous article:
But if you refresh the page, you may notice that the sanitization and serialization do not seem to work when retrieving the data. And that’s what we’re going to look into in the next post.
So that’s where we’re going to pick up in this article.
The WordPress Widget Boilerplate: Refactoring Part 11
Before writing any code, the first thing to notice is that if you populate one of the content areas of the widget (like the title) with something like this:
⚠️ Hey, Wait!
Thanks for your interest in this article! Note that it’s available to members only. If you’d like to review this (and have access to all previous and future articles), check out the membership benefits.
Ready for the Front-End
At this point, we have a mechanism in place that can flush the widget cache whenever we want – not just with a custom event – but with any of the events offered by WordPress, too.
This can come in handy if you’re using the Boilerplate for something that will use a cached query or any other caching mechanism, for that matter, and want to make sure the contents are clear.
Next, we’re going to look at rendering content on the front-end. We’re nearing the end, of the refactoring of the Boilerplate but there’s just a bit more to do before we’re ready to merge it into the master branch of the codebase.
