One of the features that I’ve often found myself having to implement when building custom solutions for others is implementing some type of select box – be it multi-select or single select – or another similar input element that’s [naturally] populated with a list of option elements.

These options may consist of posts, pages, custom post types, categories, taxonomies, etc. It doesn’t really matter what type of information it includes, but it does matter how the information is populated.

WordPress Meta Data: A Use Case

Assume the use case is something like this:

  1. The input element is populated with a list of custom post types
  2. The user has the ability to associate himself or herself with a single custom post type
  3. The user selects the custom post type from the dropdown and then saves the information
  4. The information from the custom post type is then associated with the user’s meta data

Straightforward, right? If you’re worked with WordPress long enough, then this is likely how you’re implemented certain features.

 

WordPress Meta Data

If, however, you’ve not worked with building a feature like this before, then there’s a change that you may end up making a couple of mistakes when implementing the solution.

An Implementation

Here’s a quick run down of what I’ve found to be useful when building something like this:

  • Always use the post, page, custom post type, category, taxonomy, etc., ID to populate the `option` element’s value.
  • Use the data type’s title as the text of the element so that the user is aware of what they are selecting.

The second point seems to be intuitive, but the first point is one that I’ve seen implemented in a couple of different ways. Namely, I’ve seen other developers using the same data to populate the text of the option  – such as the title – as the value of the option element.

Initially, this may seem to make sense. I mean, saving this to the user’s meta data is easy enough and then retrieving the data via, say, get_page_by_title would seem easy enough.

But this doesn’t take into account characters that could cause problems with queries. For example, ampersands, quotes, apostrophes, and other entities can yield problematic results when using this as the value of the option.

Additionally, it may not only showcase problems when displaying them in the browser, but in saving the data, and/or retrieving the data, too.

Succinctly put:

  • Use IDs are the `value` attribute of your `option` elements
  • Save the IDs to the meta data for whatever it is with which you’re working
  • Use the title (or description or whatever long form) to display the content so the user is aware of what they’re selecting
  • Retrieving the information later using the ID that you’ve saved

This can save a lot of trouble in saving and retrieving information with your results.

A Note About This Strategy

WordPress Lead Developer and 10upper Helen Hou-Sandi brought something to my attention earlier today:

This is something that’s definitely important to take into account – especially with some of the things coming down the pipeline in future versions of WordPress – but this is also something that’s a bit more technical for this particular post.

A follow-up will eventually make its way here to the blog – but not in this post :).