For years I’ve used custom fields (post meta) in WordPress as a primary storage area for misc. data about specific posts (including pages, custom post types, etc.). Recently, I’ve realized that I should be using custom taxonomies instead of custom fields in a variety of situations.
Custom fields are still the right choice for misc. data that is used for display purposes only, or descriptive data about a post that is used by a behind-the-scenes process. You can serialize data here to store the equivalent of cached relational data. You can set flags for various behavior triggers, etc. You can also create a custom user interface for adding and editing the data you need to store.
Where you should use a custom taxonomy instead is for any data that you need to query on. For example, getting all posts that were broadcast to Twitter; all posts that were created by an outside process; all posts that have a certain workflow status.
The reason to favor a custom taxonomy in these situations has to do with the WordPress database structure. Queries by taxonomy are well optimized as this is a primary front-end presentation feature in WordPress core. Conversely, querying by custom field key and value is slow. The value column in the custom field table is not indexed – you are basically doing a search through data that is not intended for that purpose.
(Yes, as a workaround you can create a NoSQL-style composite key that contains both the key and value in the key column (key = ‘featured-yes’ instead of key = ‘featured’ and value = ‘yes’), but there are only a handful of solutions where I’ve thought this is a more elegant solution than using a custom taxonomy.)
Remember, you can still create a custom admin UI for your custom taxonomy (perhaps to enforce single selection, hide certain options in certain situations, etc.). Or you could choose not to expose the data on the front or back end at all and just manage it in code behind the scenes. However, if you do want to expose it, WordPress already has a bunch of tools to let you do this (clean URLs, pagination, feeds, etc.).
I think my previous mindset of being focused primarily on using custom fields is partly because they existed before custom taxonomy support was part of WordPress core. One of the hardest things to do as a developer is realize when things have changed and part of your library of knowledge is no longer accurate/relevant. I know I harbor grudges against various apps, platforms, etc. that are certainly based on outdated information (I just don’t know which ones). 🙂
Alex King: Custom Fields vs. Taxonomies http://t.co/AbZnjVV
Alex King: Custom Fields vs. Taxonomies http://t.co/i2GJESy #wordpress
[planet wordpress]: Alex King: Custom Fields vs. Taxonomies: For years I’ve used custom fields (post meta) in Wo… http://t.co/RND14sM
Alex King: Custom Fields vs. Taxonomies: For years I’ve used custom fields (post meta) in WordPress as a primary… http://t.co/PkYqmwS
Taxonomies work better when your custom data is something that many posts will share between them. If the data is of a fixed set, or small in number, or just generally shared amongst several posts, use a taxonomy.
Postmeta is better when the data is unique, or for display purposes, or not shared amongst several posts… Basically for anything that doesn’t fit into a taxonomy, basically.
Another way to think of it as the value part of the key=value pair. When the data that actually comprises the value matters, then use postmeta. When the data that actually comprises the value doesn’t matter quite as much as the shared nature of that data amongst many different posts, use a taxonomy.
Alex King: Custom Fields vs. Taxonomies – For years I’ve used custom fields (post meta) in WordPress as a prim… http://t.co/NAK9Uby
New on @alexkingorg: Custom Fields vs. Taxonomies http://t.co/uikjGvM
I’m working on something related to this issue right now. I have some posts that have a couple of dozen custom fields and I’m investigating which ones should be custom taxonomies and which ones should be left alone. One that I’d like to convert is location data, namely city, state and country, since I have dozens of posts that can share one city/state/country. But I’m still struggling to wrap my heard around how to do it efficiently and how to present a public interface for users to that add that.
Also, I’m very pleased at how easy it was to convert regular posts to custom post types and even regular tags/categories to custom taxonomies. WordPress is a very versatile platform that has made major leaps over the past couple of years.
Nice addition Otto. Examples help too:
1) Not much point creating an (accurate) Height taxonomy for a set of posts about people – too many possible heights (152cm, 153cm, 154cm…). Better to use a custom field here, especially if you want to be able to find an average height or do any math with the data. The same would be true for Price if the important thing is being able to add them up.
2) But if, say, you didn’t care about doing math, just about grouping people by approx. height then you could create a taxonomy with names like “150-159cm”, “160 – 169cm”…
Similarly if the important thing about Price is being able to print a list of products costing £50 then a Price taxonomy will work too.
[…] – Alex King […]
Understanding WordPress’ Custom Fields vs. Taxonomies http://t.co/vYuUbSX
Custom Fields vs. Taxonomies : alexking.org http://j.mp/pjDdgy
GRS: Alex King: Custom Fields vs. Taxonomies: For years I’ve used custom fields (post meta) in WordPress a… http://t.co/7Z2ffwK
Alex King on Custom taxonomies vs custom fields: http://ow.ly/6gAbu
Good food for thought Alex. I’ve unthinkingly used postmeta for “flags” time and again, thinking that the multiple joins required for a taxonomy query would be less efficient than the single join for postmeta. I’ll have to use the taxonomy approach in those situations in the future.
However, one other reason it’s nicer to use postmeta from a developer point of view, is that the API is much easier to use and grok.
When post formats were launched in 3.1 I went through the same thought process of changing how I did things, primarily because of how I could expand capabilities of a term easier, instead of register new rewrites, etc., of a meta value.
It’s good to here my decision pays off with optimized queries; thanks, I didn’t even think about how the data is stored except how content_types can relate to each other with a term.
http://t.co/MZbjQn8 We should be using taxonomies for some things we use custom fields for.
[…] Alex King has a blog post describing the major differences between using custom fields and taxonomies in WordPress. If you are familiar with the WordPress database, and if you think about it for a couple of minutes, you’ll probably realize why taxonomies are a better choice than custom fields for those situations where you can use both. The reason to favor a custom taxonomy in these situations has to do with the WordPress database structure. Queries by taxonomy are well optimized as this is a primary front-end presentation feature in WordPress core. Conversely, querying by custom field key and value is slow. The value column in the custom field table is not indexed – you are basically doing a search through data that is not intended for that purpose. […]
Great! I am going to redesign my website with WP. I understand which part of data should be import as post meta now~
If you ever wondered which kind of query was more efficient: Custom Fields vs. Taxonomies by @alexkingorg http://t.co/JE4JFS2HVG #wordpress
#WordPress #ProTip Don’t store taxonomical data in post meta. Use a taxonomy. That’s what they’re for!
@EricMann And it’s oh so much more performant for querying.
@JS_Zao @EricMann if you haven’t seen this: http://t.co/f5hz5OhqTL
@Jtsternberg @EricMann That post was my first legitimate exposure to that revelation 🙂