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.

Endorsement: Carrington CMS Framework

When I first encountered the Carrington Theme CMS Framework for WordPress I was underwhelmed. First, I didn’t get it. Why would I want to learn a new set of concepts and functions to help me customize WordPress? It is the same reason I’ve always resisted learning third-party design programs like Dreamweaver. Wouldn’t my time be better spent learning the programming language itself?

Moreover, I was confused because Carrington Theme didn’t seem to make it any easier to turn WordPress into a CMS! It made it harder because there was yet another layer of abstraction to worry about.

But my negative assessment was born of ignorance more than experience. It wasn’t until I was knee-deep into my first CMS project managing more than 10,000 pages of content with at least 10 different “content types” that I began to remember the Carrington Framework … and then click! it all made sense.

Carrington is a framework built to help developers manage sites with hundreds of customizations. I built my CMS site without Carrington and my sidebar.php file looks like Frankenstein on acid: include, conditional, biconditional, include, exclude, uhg. Sometimes when I need to fix a particular customization it takes me ten minutes to figure out which include file it’s in.

The whole point of Carrington is to make 90% of that conditional code unnecessary because so much of it is predictable. If you’re building a CMS, you can pretty much guarantee that you want change the sidebar depending on the context of the page, right? Carrington just makes it simpler to do so.

Perhaps the confusion over Carrington is that it markets itself as a “CMS Framework”. But in fact, it’s a THEME framework for CMS builders. If you are using Carrington, you will still need to know how to use WordPress custom fields and write panels etc. But the theming will be 100 times easier.

Site Plug: ReadyMadeWeb.com

For those of you on a budget (me me me me), www.readymadeweb.com is a great resource for web tips about easy-to-use, out-of-the-box, ready-made web-ware. Is there a record for the number of hyphens used in a single clause? For instance, here’s a great post explaining why you might want to use a mass follow program to grow your twitter audience.

Meta Tag Titles and Descriptions for Your WordPress site.

There are many good plugins out there the help you easily add meta tags to your site. All-in-one-SEO is probably the most popular of all the options. But there several reason why you may want to manually add this code to your template.

For one, you may be a template designer and want your templates to come pre-installed with this SEO friend feature.

Second, you may be having issues with Facebook link sharing not working. WordPress plugins use the wp_head() hook to access your template. But you have no control over the order. If you are using more than a dozen plugins your meta tags can get buried under tons of other code. This can prevent some bots from finding them. Indeed on several of my site Facebook’s bot was not finding them.

Third, it is just always good to do things without plugins if possible. Call it Occum’s Razor of web site building, the less code you use, the better.

Luck for us, it is extremely simple to add code for meta tags and descriptions without knowing much about wordpress or PHP.

Open the header.php file in your theme and paste in the following code:

<?php if(is_singular()) { ?>
global $post;
<?php $recent = new WP_query('p='.$post->ID);
while($recent->have_posts()) : $recent->the_post(); ?>
<meta name="title" content="<?php the_title(); ?>">
<meta name="description" content="<?php the_content_rss('', TRUE, '', 50); ?>">
<?php endwhile; ?>
<?php } else { ?>
<meta name="title" content="<?php bloginfo('title'); ?>">
<meta name="description" content="<?php bloginfo('description'); ?>">
<?php } ?>

So what’s going on here? First, we’re checking to see if the post is a single post using the WordPress Conditional tag <?php if(is_singular()); ?> because we’ll to pull the title and the description of the individual post for our meta tags. But to do this, we need to get some information about the post, which is why we use the call global $post. This will give us information about the current post. Particularly it allows us access to $post->ID to query information about the post using WP_query.

The query we us looks like this:

$recent = new WP_query('p='.$post->ID); 

Once we have the query we put it into the standard wordpress loop:

while($recent->have_posts()) : $recent->the_post();

Then we use the standard WordPress tag <?php the_title(); ?> to pull in the META TITLE and <? the_content_rss() ?> to get the description. Notice, we are not using <?php the_excerpt(); ?>. This is because this WordPress tag prints the excerpt with a “read more” link in it. This will seriously screw up your theme. Using <?php the_content_rss(); ?> allows us to specify how many words of the content to pull in. But the second parameter has to be set to TRUE to avoid pulling in a “read more” link.