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 populated with a list of
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:
- The input element is populated with a list of custom post types
- The user has the ability to associate himself or herself with a single custom post type
- The user selects the custom post type from the dropdown and then saves the information
- 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.
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.
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
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
Additionally, it may not only showcase problems when displaying them in the browser, but in saving the data, and/or retrieving the data, too.
- 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:
@tommcfarlin what happens with data migration or other ID changes? See: shared term splitting.
— Helen 侯-Sandí (@helenhousandi) March 31, 2015
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 :).