As far as refactoring the WordPress Widget Boilerplate is concerned – especially given how far we’ve come since the project started eight years ago – we’ve done a lot of work.

We’ve brought it up to a far more modern standard and we’re making it far easier to work with it such that building future widgets should be easier. And this is not only from the standard of the boilerplate but from an object-oriented standard so that maintenance and code quality is higher.

In the last post, we wrapped up much of the work for the administration area and are ready to begin our work on code for the front-end.

We said:

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.

So in this post, we’re going to pick up there. Now if you’ve been following along up to this point then you should have everything you need from the develop branch.

If not, be sure to pull it as that’s where we’re going to pick up in the remainder of the post.

The WordPress Widget Boilerplate: Refactoring Part 12

Now when it comes to the front-end, it’s easy to think of the front-end as anything the user sees before them regardless of if it’s in the administrative area or not.

However, this series has been clear that we’re dividing what the user sees between the administrative area and the public-facing area of the site.

So what we’re going to be doing is working on the area of the code that renders information for the user on the public-facing area of the site. We’re going to start off by simply reading the information and displaying it.

Then in the next post, we’ll look at working with conditional logic regarding some of the options to see if there’s anything we need to do.

With that said, let’s move into the code.

[restrict paid=”true”]

On the Data We Will Display

Remember, the widget, at this point, has three things that influence its display:

  1. the widget title,
  2. the widget content,
  3. a toggle as to whether or not we should display the title

The third option is primarily to show how to use a different type of element. Because, technically, if we didn’t want to show the widget title, then we’d just not put anything into the widget.

But I think it helps to show to use different element types and their values in a practical (or semi-practical) way.

Anyway, with that said, we know that for every given instance of the widget, data is stored with the titlecontent, and display-title name and IDs as provided by WordPress.

Thus, we’ll be using those in our front-end code to display the values.

Preparing the Display Functions

Typically, the widget function is responsible for displaying the output of the widget. But one of the things we’ve been trying to do is to separate the concerns of our widget into a more focused set of classes and functions.

The first thing we want to do is to write a WidgetDisplay class that will be responsible for, as is surely evident, display the contents of the widget.

For now, this will unconditionally include the title, the content, and the value of whether or not to include the title. WordPress also makes available certain content like markup that should appear before the widget and after the widget, so we’ll make sure to include that as well.

But first, let’s just stub out the class:

After that, we need to make sure we’re writing it up to the other classes as well. First, we’ll make sure to include it in our Widget class:

And then we’ll add it to the WidgetAdmin class (since this is where the core Widget API functions reside – it just delegates responsibility to the proper class):

At this point, we’re not displaying anything yet. We’re close and we’ll focus on that soon.

Displaying the Data

Assuming you’re able to add the above code with no errors, it’s time to display the content of the widget.

We can do this any number of ways from a simple var_dump to actually working to display the content in a more user-friendly manner. And I’m far more a fan of the latter.

So let’s do that.

In the show function of your WidgetDisplay class, add the following code:

And then the view for the template can be as simple as this:

This will make sure the proper markup for all content prior to the widget, the content of the widget, and the content is properly rendered.

Again, remember that we are displaying some content that won’t be in the final version of this but we’re getting close and we’ll be addressing it in in the next post.

I’d recommend toying around with the Display Title option to see how it renders on the front-end given the markup we’ve provided.

For now, the output of the widget should look something like this:

The WordPress Widget Boilerplate: Refactoring Part 12 - Example

But that’s all there is to cover in this post.

[/restrict]

Into the Final Refactor

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).

For now, though, feel free to toy around with what we have here along with the code that we haven’t included (like what can be displayed before or after the widget.

They’ve been deliberately left out of this example but they may not always be left out depending on the work you’re doing.