Today, a lot of developers use custom fields to store data for their custom post types. Plugins for custom fields such as Meta Box provide an easy way to create them with tons of options. Developers don’t need to handle the UI, outputting and saving data. But are custom fields always good? Do we misuse them?

Another question that I usually see developers are confused about is when to use custom fields and when to use custom taxonomies? Should I use a taxonomy instead of a custom field or vise versa? Assume that you have a custom post type “Book” and you want to store publisher name. Will you store it as a custom field or a taxonomy?

In this post, I will try my best to answer these questions.

Why do we need custom fields and taxonomies?

Back to history, when people use WordPress most as a blogging platform. You write posts and publish them. To write posts, you just need to fill in some fields such as title, content and hit the “Publish” button. That’s all.

Since version 3.0, WordPress gives you the capability to add your own custom post types and to use them in different ways. Your website can contain more content types than just “post”. They can be “listing” for a real estate website, “product” for an e-commerce website or “hotel” for a travel website. Custom post types turn WordPress into a more powerful CMS, not just a blogging platform.

This change also raises a question for developers: how to add more info for the new post types? Such as area, location, price for a listing; or manufacturer, size, price for a product. Obviously the post title and content are not enough for other types of content. They need a better way to add different kinds of info to posts.

And the solution to this problem is custom fields and taxonomies.

It’s worth noting that custom fields and custom taxonomies are added to WordPress before custom post types. Custom fields are there since the beginning, while custom taxonomies are added in version 2.3. But they’re not widely used until custom post types is added.

Now the question is: when to use each of them? To answer this question, we need to get back to the basics to see their main purposes.

What’s the difference between custom fields and taxonomies?

According to WordPress Codex, custom fields store arbitrary extra information for a post, while taxonomies are ways to group posts together.

So, the main difference between custom fields and taxonomies here is grouping. This example from Samuel Wood (also known as Otto) explain the difference quite well:

Let’s say I’m building a new site, and I want to make, say, television shows be a custom post type. What makes sense as a taxonomy for a TV Show? Title? Actors? Episode numbers? Season numbers? For each item, you need to consider whether it makes more sense as a taxonomy or as pure post meta, or (rarely) both.

Titles makes perfect sense for a taxonomy. You’re grouping all the episodes of that show together, and people will want to see an episode listing. So yes, it’s a taxonomy.

Actors also makes sense as a taxonomy. Actors act in many roles, it would be nice to see what various shows and episodes they’ve been in.

Season and Episode numbers is another one. Every show has it’s own season and episode number. At first glance, season numbers kinda makes sense as a taxonomy, since you can pull all of season 1 out. But on further reflection, no it doesn’t. Every TV series has a season 1. We don’t want to pull out all season 1 shows from all series. Same goes for episode numbers.

We can highlight some key points here:

If you have meaningful meta data to assign to a post, use custom fields. If that data is used to group posts together, use taxonomies.

Custom fields is bits of information that are specific to the post item itself. Taxonomies are bits of information shared, in a meaningful manner, by many different items.

Querying Posts

Another common problem between custom fields and taxonomies is querying posts that have a specific value. With the meta query and tax_query , you can make a complex query and get the posts you want.

But there’s a thing you should know here: you can order posts by custom fields, not by taxonomies. This is due to the way WordPress saves data. With custom fields, it saves both meta key and values, thus you can order by values. With taxonomies, it saves only the key ( term_id ) which is a reference to the terms table.

That’s quite easy to understand: custom fields are attached to posts and can be considered as a part of posts. You can order posts by that. While taxonomies are groups of posts, ordering by taxonomy doesn’t make any sense since each term has a group of posts.

Another thing that you should consider when structure your data: query performance. Because of the WordPress database structure, querying posts by taxonomy is faster than querying by custom fields. 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. Even when you add an index to the post meta table, it won’t fix.

It’s worth to remember that taxonomies are built to organize things and provide a way of filtering down to a specific set of posts. Post meta should only be used for information that isn’t going to be searched of filtered for.

Front-end Template

A big difference between custom fields and taxonomies: taxonomies have templates, custom fields don’t. WordPress offers several different hierarchies of templates for custom taxonomies: taxonomy-{taxonomy}-{term}.php , taxonomy-{taxonomy}.php , taxonomy.php .

With custom fields, you don’t have that. You need to make a custom page template, then put a custom query to get posts and use helper function to show the info. You have to do many works by yourself. And as mentioned before, if you have to query by custom fields, make sure you avoid performance problem.

Conclusion

Making the choice of using custom fields or taxonomies might affect your website in long term. While you can do almost the same thing with both of them, a wise choice can save you tons of time developing.

So, here is the table that can help you make a better decision: