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.

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.

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.