↑ Return to Data in WordPress

Da06 Metadata in WordPress

Page no: Da06

Page no: T21f

So far in this series, we’ve looked at the main content types in WordPress. But what about the additional data about all that content?

That’s where metadata comes into play.

As I covered in an earlier part of this series, WordPress has four main content types which it stores in four database tables:

  • posts
  • users
  • comments
  • links

The first three of these can also have metadata assigned to them, and each has its own metadata table in the database to store this.

Metadata can be described as data about data. Wikipedia defines two types of metadata:

Structural metadata is about the design and specification of data structures and is more properly called “data about the containers of data”; descriptive metadata, on the other hand, is about individual instances of application data, the data content.

By this definition, WordPress uses descriptive metadata. What we define as data in WordPress and what can be defined as metadata is a little blurry, and doesn’t equate directly to what’s stored in the metadata tables. For example:

  • For posts, post_type is an example of metadata, but it’s stored in thewp_posts table
  • Taxonomy terms, categories and tags can also be loosely defined as metadata, but these are stored entirely separately, in their own database tables.
  • Post metadata such as custom fields and additional metadata added via plugins is stored in the wp_postmeta table, as you would expect.

So it’s easier to think of metadata in WordPress not according to the strict definition of the term, but as the data stored in the three metadata tables.

WordPress uses three database tables for metadata:

  • wp_postmeta stores metadata about posts (including attachments, navigation menu items and revisions)
  • wp_commentmeta stores metadata about comments
  • wp_usermeta stores metadata about users

The only object type in WordPress which does not have metadata is the link.

The metadata tables are all nearly identical in that they have just four fields:

  • ID is the ID of the post, user or comment the metadata relates to
  • Meta ID refers to the ID of the metadata record
  • Key is the meta key (which is often duplicated between different records)
  • Value is the meta value (which tends to be unique)

WordPress can use this structure to store large quanities of metadata using a simple structure. This means that the functions you use to display and query metadata for posts, users and comments are very similar.

The metadata stored in an individual WordPress installation will vary from that stored in another installation, because plugins and themes can add their own metadata, and because in some sites you will need to define specific metadata while in others you won’t.

But let’s have a look at some of the more common types of metadata:

  • Custom Fields. These apply to posts so are stored in the wp_postmeta table. You can add them using the standard Custom Fields interface or by creating your own metaboxes in the post editing screens. This can be particularly useful when you want users to be able to add metadata to a specific post type, and you want to make the interface as user-friendly as possible.
  • User Metadata. The wp_usermeta table stores metadata about most users, such as roles, capabilities, dashboard settings and even first and last names.
  • Metadata added by plugins and themes. Plugins with comment functionality such as Akismet will add metadata to thewp_commentmeta table, while plugins which allow you to add metadata to posts, such as SEO plugins, will add records to the wp_postmeta table. You could theoretically add metadata via your theme but it makes more sense to do this in a plugin, as it is generally related to functionality and not display.

Of course the list isn’t limited to these types. In fact, any data about posts, comments or users which can’t be stored in their main database tables will be stored in the relevant metadata tables.

If you’re adding a new field to store data, you should always use these tables and not the core tables.

WordPress has a Metadata API which you use to add, amend, get and delete metadata. There are a range of functions specific to each type of metadata which you use to output metadata in your template files: you should use these instead of any generic metadata functions.

The metadata API functions for each content type are very similar and have the same parameters:

Adding metadata Getting metadata Updating metadata Deleting metadata
Posts add_post_meta() get_post_meta() update_post_meta() delete_post_meta()
Users add_user_meta() get_user_meta() update_user_meta() delete_user_meta()
Comments add_comment_meta() get_comment_meta() update_comment_meta() delete_comment_meta()
Parameters $post_id,$meta_key,$meta_value,$unique (optional) $post_id,$meta_key,$single (optional), $post_id, $meta_key,$meta_value,$prev_value (optional) $post_id, $meta_key,$meta_value (optional)

These functions can be used in your template files and plugins, for example in your theme’s single post template, you might use the following to output metadata about the post:

This is just one very simple way to output some metadata – there are plenty more possibilities, some of which I’ll cover later in this series.

WordPress uses three metadata tables to store data about three content types: posts, users and comments. These tables are used for anything not stored in the core wp_posts, wp_users and wp_comments tables, and are the tables you should write data to if you are adding new fields via themes or plugins. The three tables work in almost identical ways and have very similar functions which you can use to add, update, delete and get metadata.

As I mentioned above, taxonomy terms could be seen as another type of metadata in WordPress, and these are what I’ll cover in the next part of this series.

See more for Data in WP