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:

[restrict paid=”true”]

And then click on Save, the actual content will be sanitized and written to the database. You can see this is true by looking at the widget’s value in the database.

WordPress Widget Boilerplate: Widget Database

Further, the data looks fine at first glance but if you refresh the page, the unsanitized content appears. If you navigate to another page, like Menus, and then come back, the widget content appears but properly sanitized.

Why, then, does it show one thing in the database and one thing on the front-end of the administration area when performing certain steps?

This has to do with the widget cache and luckily, we’re able to flush this cache at will using whatever hooks we want (that is, we can subscribe to any event and then have it flush the cache).

WordPress Widget Boilerplate: wp_cache_delete

From the Code Reference:

Removes the cache contents matching key and group.

Note, however, that it requires we provide the key and an optional group. In the Boilerplate, we’ve been using the widget’s slug as the key and group is widget.

Clearing the Cache

Since the function can be hooked to any event, we can create a subscriber that we can hook to any event. This means we can create DeleteWidgetCache subscriber in our Subscriber namespace:

We’ll then update the bootstrap to add the subscriber to the registry and we’ll use a custom hook, flush_widget_cache, that we’ll use momentarily.

For the purposes of the Boilerplate, we’ll use the custom event whenever the widget serialization code is called.

First, we’ll define a do_action call, identify it as flush_widget_cache, and then we’ll pass the necessary arguments to the event so that the subscriber can read them:

And then in the subscriber, we’ll flush the cache based on the incoming arguments:

And that does it.

[/restrict]

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.