Utilize available post fields for Custom Post Type

When store meta data for a post type, we often think of custom fields first. This is reasonable because custom fields are born to store such custom meta data for posts.

As we know each custom field is stored in 1 row in the postmeta table in database. If a post type has large number of custom fields (like a song has artist name, album, year, genre, length, bitrate, …), then for each post of that post type, it will take the same number of rows in the postmeta table. The total number of rows in the postmeta table for only that post type equals to number of posts multiplied by number of custom fields.

This is not a big problem if we has small number of posts or small number of custom fields. However, when the number of custom fields is large and your website continuously creates more posts, then the postmeta table is getting bigger and bigger. If that happens for a long time, your database will be huge and access to the database will be much slower.

Examples of increasing database size are contact form entries, orders or bookings in ecommerce websites. The number of custom fields for these post types is fixed and quite large (order can have shipping address info, items, quantity, coupons, etc.). And the number of posts with these post types are created daily. That makes your database bloated.

The worst thing is each row added to the postmeta table stores little information (only post_id, meta_key and meta_value). If each row can store more meta values, then we don’t need many rows.

There’s a solution to reduce number of inserted rows into the database – utilising available post fields and available data types of WordPress instead of custom fields.

That means we use available fields of the posts table to store information with same format. The posts table of WordPress has many fields that are rarely used for some post types such as post_date, post_excerpt and we can utilize them to store data for those post types.

Examples:

  • Instead of storing a paragraph in a custom field (like song lyrics), we can store it in post_excerpt.
  • Instead of using a custom field for order date, we can use post_date.
  • Instead of storing testimonial author name in a custom field, we can use post_title.

Beside post fields, WordPress has some default data types which we can utilise to add more data to post without using custom fields like comments or user fields.

Real examples

To illustrate things above, let’s see some examples which are used (very smart) in reality. If you know more examples, please let me know in the comment.

1. WooCommerce order post type

  • Each order in WooCommerce can has many notes, WooCommerce uses comments for these notes. Each note is a comment of the order. (I’m impressed by this method)
  • Uses post_status for order status. They create custom post statuses. You can know how to do that in the Codex.

2. Testimonial post type

At the moment, there are some results around standards for post types, taxonomy and meta data. This is the community effort to make a standard for custom post types for plugins, themes so they can use the same data without worrying losing it when switch to another theme or plugin.

Among standalised post types, testimonial uses some post fields for meta data:

  • Use avatar or featured image for customer’s image
  • Use post_title for customer’s name

Currently there is a plugin Testimonial By WooThemes does the same thing (although it doesn’t follow the standard above for some fields).

Conclusion

Utilising available post fields and data types of WordPress instead of custom fields is an effective way to reduce number of rows in the database, thereby increasing the speed of data access. However, when apply this method, you have to think carefully about which data types are suitable before using to avoid not to be changed later.

Newsletter

Subscribe to our newsletter to receive news and tutorials about WordPress and web development.

60% OFF for Meta Box Lifetime Bundle Get It Now