WordPress Widgets: Refactoring, Part 13

We’re finally at the final post of the series on refactoring the WordPress Widget Boilerplate. By the end of this post, we’ll have the development branch of our code done, and we’ll be ready to merge everything into the master branch.

There is, however, still a bit of work to do. Namely:

The last thing we’re going to look at after this is tightening up some of the conditional logic along with a word about caching data (since we’re already doing a bit of that in earlier posts).

So those are the two things we’re going to be looking at in this post. Specifically, we’re going to look at handling conditional logic for the front-end and then how to implement basic caching.

The WordPress Widget Boilerplate: Refactoring Part 13

Before we get into the final round of details, I want to make sure that you’re running the latest version of the code as this is the one time in which I believe it’s imperative to have the code ready for the final round of changes.

WordPress Widget Boilerplate: The develop Branch

So if you don’t have the code running on your machine, now’s the time. The last bit of code that we need to work on is fairly small.

But it’s important to make sure you’re running the latest version. So once you’ve done a pull of the latest code, we’re ready to wrap this up.

1. Rendering the Front-End

Recall in the previous post, we rendered general widget information – the title, the content, and whether or not the title should be displayed – by simply displaying the values on the front-end.

But now it’s time to set up information to make sure that we’re not only going to render information based on the options in the administration area of the widget, but also if there’s any information at all.

So we’ll start with the simplest option: The option that allows us to toggle if the title is displayed. In other words, we’re going to assume if the values are populated and that option is checked in the backend.

Recall, the Widget.php file currently looks like this:

So we’re going to be refactoring this part, first. Of course, it’s a relatively easy thing to introduce, right? That is, the logic goes like this:

  • If the option for displaying the title is checked, then we show the title; otherwise, we don’t.

This can be tackled with a simple if statement by evaluating the value of the display-title option we have. Because of the way we’ve built the function throughout this series, if the option is checked then it has the option of on; otherwise, it’s empty.

This means we can set up a conditional like this in the very same code that we’ve shared above:

This way, if the option is checked, then the title will be displayed.

A Corollary to This

One thing I think is worth mentioning is that there are times where people can activate widgets but opt to have no content. Sure, you can argue that if they do that, then it’s their fault.

There’s truth to that.

But I also think that taking care of users who may be figuring things out or who may have accidentally done something that they didn’t know they can help them. Perhaps it makes us responsible developers (or perhaps it makes us more aggressive – take your pick, I’m with the former).

So in this case, I think it’s worth making sure the title and the content aren’t empty. If they are, then don’t render anything.

The code then looks like this:

And that will wrap this up as far as the front-end is concerned. But what about the caching that we talked about in an earlier post?

2. Introducing Caching

Caching, for a widget like this, is something that I consider to be optional but since we’ve built the basic functionality into the Boilerplate for flushing the cache then it logically follows to introduce the functionality for caching data, right?

So let’s do that. It shouldn’t be hard, either. In reality, we’re simply taking the title, content, and checkbox and caching the values for the given instance of the widget.

To do this, we need to locate the widget function and then do the following:

First, we’ll introduce a function for caching the widget:

Then we’ll introduce a function for retrieving the cached version of the widget:

Then we revisit the original function to make sure we’re displaying what’s needed. If the cache is empty, then we don’t do anything but display the values as they stand.

And that wraps up the functionality for the completely refactored Widget Boilerplate.

The End

This particular serious has been long. Personally, it’s been really good to revisit the WordPress Widget Boilerplate and bring it up to more modern standards.

There are still a few things I need to do like update the README file and then provide a few more instructions before I merge it into the master branch, but if you’ve been following along this entire series, then you’re likely on board with everything. Further, I appreciate your time in hanging with it, and I hope that it was beneficial for you on some levels.

With that said, I’ll be looking to move into shorter form premium content since this series and the last were quite long. As usual, you can always contact me or offer pull requests as necessary – it is open source and it welcomes improvements, too.

For now, though, this wraps this series.