Modular Procedural Programming The WordPress Theme Customizer

One of the things that I love about working with WordPress is the entire hook system – you know, the various add_action and add_filter calls that you can make in order to manipulate content prior to sending it up to the browser.

I think that it provides a really powerful mechanism for working content prior to saving it to. or retrieving it from, the database.

Now, to be clear, I’m not someone who thinks that everything should be object-oriented versus functional versus procedural. Generally speaking, I think that certain paradigms lend themselves to certain strategies more so than others.

Case in point: The fact that WordPress functions.php file is nothing more than a collection of functions is fine with me; however, I really like the fact that I can write plugins using object-oriented programming.

Anyway, one of the the things about the hook system is that it can result in writing repetitive code – which I’ll show in a moment – which can in turn make for very long, very tedious, and very redundant functions.

Or, more generally stated, it can result in less than stellar programming practices.

So when these situations arise, I try to look for opportunities that help to keep functions lean, but yet maintaining a purpose, as well as easy to follow. I think it pays off significantly when it comes time to read back through the code, maintain the code, and to document the code.

Modular Procedural Programming

For example: One of my favorite things about the latest versions of WordPress is the Theme Customizer.

The actual implementation details of the feature are beyond the scope of this post, but have already been covered (so check them out, if you’re interested).

But here’s the thing; The way in which features are implemented can be reduced to a five step process (which is good, in my opinion), but which can also result in repetitive.

First, the process can be distilled into the following:

  1. Create a Section
  2. Add a Setting
  3. Add a Control
  4. Write the necessary JavaScript
  5. Make the call to get_theme_mod

For those of who you have worked with the Theme Customizer, you know exactly what I’m talking about.

Lengthy Customization Code

This means that if you’re adding but one new section, the function for doing so can end up looking like this:

Long, tedious, and repetitive, isn’t it?

Now I love the fact that the Theme Customizer has a very clear, capable, and easy to understand API, but when it comes to implementing functions that add new options to the Theme Customizer, I’m not such a fan of large functions.

To that end, I try to keep the functions small, purposeful, and easy to understand.

A More Modular Approach

Take, for example, the following refactoring of the code above:

It’s still a lot of code, but I think that it’s easier to follow and to understand:

  1. The Theme Customizer is registered
  2. A new section is added
  3. Each Setting and Control related to a given section have their own function keeping their implementation small and focused

A bit easier to follow, isn’t it?

For those that are curious, I prefixed the Setting and Control functions with an underscore to denote that these functions are a type of private function, or that they are more closely related to the function in which they are being called – in short, they aren’t meant to be stand alone functions.

They aren’t hooked to anything – they are called from a hooked function.

It’s More Than Trivial

Perhaps you view this as a trivial refactoring – and, in a sense – it is, but trivial refactoring can go a long way in making code easier to read, easier to manage, and easier to document both from an automated standpoint, and from a user stand point.

As developers, the purpose of our job is not just to get something working, nor is it just to get something working well.

It’s also to make sure that the code that we’re writing is easy to follow, well-organized, and can be maintained over time either by ourselves, or by someone else that comes up after us – be it a team or a single developer.

At any rate, this is an example of some of the work I’ve been doing on a couple of projects, and how I’ve found to help make implementation, development, and maintenance a bit easier moving forward.

4 Replies to “Modular Procedural Programming The WordPress Theme Customizer”

  1. Tom,
    if I wanted to create options for my clients to change dozens of elements of their site, like typography, headings, colors, etc – is it your advice to do so through the customizer rather than through an options panel?

    The options input here that relate to styling still need to be loaded into another function to add those styles into the document no?

    1. if I wanted to create options for my clients to change dozens of elements of their site, like typography, headings, colors, etc – is it your advice to do so through the customizer rather than through an options panel?

      To be honest, I don’t think themes should have “dozens of elements.” I’m more of a fan of opinionated design and development where certain things – like fonts, spacing, color schemes, etc. – are provided for them, and they have the ability to change what widgets are where, the background color of page, or, perhaps, if the sidebar is on the left and right.

      To that end, if you’re going to introduce dozens of options, I still think that including them in the Theme Customizer provides a better experience for the user because they can instantly see the changes of their settings rather than toggling back and forth between the dashboard and the page.

      The options input here that relate to styling still need to be loaded into another function to add those styles into the document no?

      More or less, yes – check out this series for more information.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.