Making your Pods Input Helpers a Bit More Helpful

I’ve always based my opinions of content management systems on ease of use not only when it comes to implementation on my part, but more-so on the usability for the client once I’ve handed over the keys. What good is a CMS that your client can’t use? You’ll be spending more time tutoring than you will working on the next (billable) job.

That’s one of the reasons I really like Pods. While one inescapable argument I’ve had with myself since discovering Pods is the fact that clients are very likely to become confused with the implementation at a certain point. Not by the fault of Pods itself, but the way it’s bound to be used. This is where the conversation bridges itself into the philosophy of combining Pods and WordPress for the benefit of your client; an up-and-coming article that isn’t ready quite yet. There’s just as much to be said about implementation as there is the tool, and I’m really looking forward to having that conversation with you soon enough. For the time being though, I digress.

Circling back to usability, out of the box Pods has a leg forward by simply being. It gives an interface consisting of elements strictly defined as being applicable when viewed. Awesome. While putting together a client site recently I couldn’t help but notice a usability issue I knew would come up sooner or later. For the sake of privacy, I’ll make the example a bit more generic, but equally applicable.

For example’s sake, we’ll say that I’m working on a photography history website. There is a section of the website consisting of famous photographers, a bit of information about the person, and of course some work examples. My plan is to have one Pod for the photographers, one Pod for the photographs, and use Pods UI to relate the two very easily.

The problem

With the game plan in place, we’ll first set up our two Pods:

Define the data columns:

When setting up the Photographs Pod, we’re going to set up a pick column to pull from our newly created Photographers Pod:

In particular, pay attention to the way the pick column is structured

The final Pod:

We can now begin populating some photographers:

Then we’ll add some photos:

Here’s where I discovered that a problem was a brewin’. As it stands, we’re using the name column alongside a first_name column therefore resulting in the last name controlling the slug. What happens when you add a second photographer with the same last name? You’ll be faced with a duplicate entry and your client will be left to guess, save, and check to make sure they guessed right. A possible solution would have been to re-structure the Pod from the start and use the name column for the photographer’s full name, but what if you wanted to pull data ordered by last name only?

Given the current situation, we might be in a bit of a pickle. Pods can help with that!

The solution

Input Helpers are quickly becoming a favorite feature of mine when it comes to Pods. As is the case with this particular situation, data columns aren’t quite cutting it, even when they’re as awesome as pick relationships.

The solution I cam up with to solve this problem of data integrity was to simply make the data itself that much more valuable. It would be great if we could simply append the first name alongside the last name to help decipher which dupe is which when choosing our photographer. Input Helpers to the rescue.

We’re going to write a quick Input Helper that expands upon the information originally available with a stock pick column. As it stands, when invoked, pick columns will display all of the (extremely valuable) associated data columns you already set up with your Pod. In the case of Photographers, we’re provided with the following:

• id
• first_name
• origin
• copy
• slug

All of the additional data that comes with an Input Helper is also available. What’s most interesting here is the fact that we can pull data from the Pod itself, specifically the first_name.

<select id="<?php echo $css_id; ?>" class="form pick1 <?php echo $name; ?> pods_field pods_field_<?php echo $name; ?> pods_coltype_pick">
  <option value="">-- Select One --</option>
  <?php if ( !empty( $value ) ) : ?>
    <?php foreach ($value as $key => $val) : ?>
			
      <?php
        // check to see if this is the chosen value
        $selected = empty($val['active']) ? '' : 'selected';
				
        // check to see if we have a full name
        $photog_name = $val['name'];
        if( !empty( $val['first_name'] ) )
        {
          $photog_name .= ', ' .  $val['first_name'];
        }
        ?>
			
      <option value="<?php echo $val['id']; ?>"<?php echo $selected; ?>><?php echo $photog_name; ?></option>
    <?php endforeach ?>
  <?php endif ?>
</select>

As with writing any Input Helper, we want to start by examining the markup provided by the original input field. That way we can replicate and elaborate upon what’s made available to our user.

The take home notes with this Input Helper revolve around the conditional that checks to see if we have a full name. We simply check to see if first_name has been defined, and if it has, we’ll append it to the last name and provide a much more straightforward experience for our user:

Not only does this help to prevent confusion when handing over the keys to your client, it really helps to polish the overall experience by being that much more straightforward and useful.