Practical WordPress Development

WordPress Meta Data: Use IDs (Not Titles)

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 :).


  1. Shazdeh

    I think using “slugs” would be the better choice than IDs to save data. In case of taxonomies, post types and posts, WordPress generates the slug automatically and the good news is, after migration the slugs stay the same whereas IDs might change.

    • Tom

      This was actually going to be my follow up article to this particular post (see also Helen’s tweet at the bottom of this post).

      I’m glad to see someone mention it and I’ll be sure to mention this in the next article, as well.

    • Doug

      Wait, what? If youre basing things on user-changeable slugs, titles, etc, youre going to have a bad time. WP might generate a slug, but the user/admin can change it. I’ve changed cpt slugs for seo, etc. ID never changes. I’m pretty sure youre wrong, on this; please give a scenario where an ID would change.

      • Tom

        ID never changes. I’m pretty sure youre wrong, on this; please give a scenario where an ID would change.

        IDs can change. See this paragraph in the post about IDs incrementing in database records:

        But let’s say you end up deleting posts or moving other records around and, generally, the IDs and other pieces of information don’t out of sequence (or simply aren’t as reliable as before). Then say you need to migrate the database.

        The bottom line is that there’s no one true solution on how to do this – I’ve tried to capture a couple of options in two different posts about this. 

        Sometimes one lends itself to situations better than others. To that end, you’ve got to pick the situation that works best for your implementation.

  2. Govertz

    So the take away is to use slugs? Tom you can tell me anything and I’ll believe it. :)

    And your last comment says, best practice is to use slugs, am I wrong?

    • Tom


      I wouldn’t say that the best practice is to use slugs, but it’s a very safe practice.

      There are times where IDs are suitable; however, it also depends on the nature of your setup, the project, and the plans that may change the course of what you’re doing.

      If you’re unfamiliar what may happen with your project in the future, then use slugs :).

  3. meks

    Personally, I avoid to use slugs as they can be changed by a regular user which means that all the options saved by slug may be lost anytime. And since WordPress will get rid of the strange bug with taxonomies in 4.2. I guess IDs will be the most safe and elegant solution.

    Cheers! ;)

Leave a Reply

© 2020 Tom McFarlin

Theme by Anders NorenUp ↑