WordPress as CMS, Pods or Custom Fields

If you’re looking to use WordPress as your content management system there are really only two startegies right now for doing so. First there are custom fields. Custom fields are WordPress’ native method of handling data beyond the typical post category, tags, author, etc.

There are several plugins that make working with custom fields a little easier. Custom Fields Template Flutter , and More Fields are the popular examples. These plugins provide the ability to set up custom “write panels” with new fields added for inputting custom fields.

In the latest versions of WordPress there is support for “post types” which should make it even easier to customize the post entry screen depending on the type of content you are inputting.

The alternative to this approach is Pods CMS. Pods is a WordPress equivalent to the Content Construction Kit available to Drupal developers. Pods does not use custom fields, rather it creates new tables and completely new data types.

There are advantages and disadvantages to both approaches to WordPress as a CMS. And if you are serious about building a WordPress site you need to understand those advantages.

Custom Fields


  • Native to WordPress. Does not require plugin installation to function and all posts are immediately connected to other WordPress plugins and functions
  • All fields are text formatted, which means once you know how to output one custom field, you can output them all.
  • Most plugins are already compatible with Custom Fields.


  • Queries with custom fields can be complex and convoluted. Sometimes you will need a “Custom Select Query” in order to accomplish your task.
  • All fields are in LONGTEXT format, which means the database will be larger than it needs to be and this could put limits on the scalability of your site. (More on Custom Fields Scalability).
  • End User support is still limited. The WordPress Dashboard, even with the mentioned plugins, is not fully customizable.

Pods CMS


  • Fully customizable backend. You can specify exactly what fields the end user sees for any given content type.
  • Public form support makes setting up forms for adding content on the front end relatively easy. Though the form options are limited and can be buggy.
  • Field formats are customizable, which means your database is only going to be as big as it needs to be. This also means your site will be more scalable.
  • Fields are relate-able. This is the biggest benefit to Pods. In future posts we will see exactly what this means.


  • Not supported by WordPress development team. This is truly a plugin and WordPress is hesitant to support it and would rather CMS developers use Custom Fields and Custom Taxonomies. This means if the plugin developers get tired of working on it, then your site could be toast. The good news is the Pods user base is growing rapidly and the bigger it gets, the less we will have to worry about this.
  • Pods content is not added to WordPress posts table by default which means it is not available to native WordPress functions, like comments and Akismet, and is inaccessible to many plugins, like WP-PostViews (Note: there is a patch that will allow integration, but not seamless integration).
  • Because of the complicated relational database, SQL queries are more difficult than with custom fields. Though you can do more with Pods not using SQL than you can with custom fields using SQL.

Choosing between Pods and Custom Field based development is a big decision and there isn’t a universal answer. Much will depend on the site you are building and what your goals are. But here are some questions you should ask yourself before making the decision:

  • Are your custom content types generally “post-like”? If so, consider sticking with Custom Fields.
  • Do you need to fully customize your Dashboard interface for the end-user? If so, Pods may be your best bet.
  • Do you need to rely on other available WordPress plugins/functions? If so you’ll either need to patch your Pods install, or you should stick with Custom Fields.
  • Do you need complex and relatable content types? An example would be an online journal where you need Volume, Issue, and article, each with particular information but also related to each other.
  • Are you building a very large site with tens of thousands of entries? You may need to be concerned about scalability. Look at pods.

In most cases you will find your answers will be mixed. Your content is “post-like” but needs to be relatable. Or you are building a large site, but you need to integrate with other plugins. In most of my sites, I use a combination, deploying custom fields for basic post-like content, but Pods for more specialized content types like event listings.

As WordPress develops as a CMS I expect these two solutions will come together. WordPress cannot truly be considered a CMS with an easier way to (a) relate content and (b) customize content entry pages. Pods enables both.