Though the last post in this refactoring series wasn’t incredibly long, I do think it was a bit dense. That is, it required a fair amount of work to get the code in a place that we can more easily work with it.
But that’s just it: All the work we did should make it easier to move forward with the rest of the code we need to write.
And to make sure that we’re taking advantage of the work and the foundation we’ve laid thus far, we’re going to round out the series with a set of shorter, more focused articles that should take less time to read, implement, and understand what we’re doing with the code.
The WordPress Widget Boilerplate: Refactoring Part 9
Recall from the last post:
Next, we’ll continue building out functionality for the administrative area of the widget. After that, we’ll turn our attention to the public-facing side of the widget as well as serialization functionality.
And this sets us up for exactly where we’re headed in this particular post. Namely, we’re going to be writing an administrative front-end that allows us to:
- define a title for the widget,
- define text content for the widget,
- and toggle whether or not we want to show the title.
It’s not meant to be innovative nor is it meant to be the type of widget anyone else may want to sell. Instead, it’s meant to show how we can take what we have to create something similar to what we’ve already seen in WordPress and how we employ solid programming practices.
The User Interface: A First Pass
After our work last time, we have a widget that appears in the administrative area of WordPress and it can even be moved into a sidebar or other widgetized area; however, it doesn’t actually do anything.
For now, let’s go ahead and add three elements to the user interface:
- add a text input for the title of the widget,
- include a textarea element for displaying what may be a paragraph of text,
- and lastly, add a checkbox to toggle the title information.
To do this, we’ll need to edit a file in the Views directory. Namely, we’re going to be updating the Admin.php file. We’ll start off with the elements exactly as needed with no extraneous markup.
It’s not going to make for much to look at on the front-end, yet, but it’s getting us closer to where we want to be.
A Class For Administrators
Next, we want to make sure that we’re staying consistent with maintaining a high level of cohesion with our classes. This means we don’t need a single class to do everything for administration, displaying, and all of the other work required by the WordPress API.
To that end, we’ll create a second class called WidgetAdmin in the WordPress directory and namespace.
In this file, we’ll include the following code:
Then, in the original code for instantiating our widget, we’ll change this line:
To look like this:
Over the next few articles, this is going to continue to evolve but, as you can see, we’re making sure that we have a single base class of functionality for talking with WordPress and a class specifically for rendering the administrative form.
The User Interface: A Second Pass
Finally, let’s clean up the form so it has a little bit more of solid UX that blends in well with the WordPress administration area as a whole.
And update it so that it looks like this:
Assuming all went well, you should now see something that looks like this:
And that’s where we’re going to stop with the administrative features for this post. Remember you can also track all of this in the develop branch on GitHub.
Sanitizing and Serializing
In the next post, we’ll look at what’s necessary to sanitize and serialize (or clean and save) the content of our widget.
We’ll also make sure we’re displaying the information in the administrative area after the information has been saved and retrieved.
Finally, the inheritance and class cohesion will continue to evolve but, for now, focus on what’s covered in this post and then we’ll continue in the next article.