Custom Post Types Location

First, where does this code reside? As with almost any addition, it will reside in your functions.php file or in an external php that functions.php calls through a require_once (e.g., require_once( TEMPLATE.'/lib/custom_post_type.php' );). Second, registering the custom post type needs to happen in the init hook.

Custom Post Types Namespaces

Naming of the custom post type is critical. Be sure to use a short namespace, which identifies the plugin, theme, or website (in this case, website) that implements the custom post type. Namespaces is the prefix that appears before the custom post type code name. For example, I may have a custom post type of CARS, but my custom post type code name is wps_cars. The "wps_" is a namespace. My recommendation is to create a namespace that identifies you and your brand, e.g., for me wps_, for a company called Bob Barker Media, they may want bbm_ or bbmed_. Then consistently use this prefix in front of all your functions, names, etc. to prevent conflicts.

This is important because without this namespace, it is extremely possible and even likely to conflict with a custom post type in your theme or a plugin that you use. While this namespacing won't guarantee a lack of conflict, it dramatically reduces the chances. However, be sure that your namespace does not exceed 20 characters as the post_type column is a varchar of the latter length. Also be sure to avoid the namespace "wp_" as WordPress may use that moving forward. And finally, never use capital letters.

Summary:

• Put the code in functions.php or call it from functions.php
• Naming Conventions:
  • Use namespaces (e.g., wps_) and avoid the namespace "wp_"
  • Keep name under 20 characters
  • Never use capital letters
• Registered your custom post type in the init hook

Registering the custom post type can take 25 arguments with more sub-arguments. They are:

label (string, default: $post_type):a plural descriptive name	labels (array, default: name is set to label value, and singular_name is set to name value; more below)	description (string, default: blank): A short descriptive summary of what the post type is
public (boolean, default: false): Meta argument used to define default values for publicly_queriable, show_ui, show_in_nav_menus and exclude_from_search	publicly_queryable (boolean, default: value of public): Whether post_type queries can be performed from the front end	exclude_from_search (boolean, default: opposite value of public): Whether to exclude posts with this post type from search results
show_ui (boolean, value of public): Whether to generate a default UI for managing this post type	show_in_menu (boolean/string, default: null; false-no menu item, true-top level admin menu item, some string-top level page like 'tools.php'): Whether to show the post type in the admin menu and where to show that menu	menu_position (integer, default: null): The position in the menu order the post type should appear
menu_icon (string, default: null): The url to the icon to be used for this menu	capability_type (string/array, default: "post"): The string to use to build the read, edit, and delete capabilities	capabilities (array, default: capability_type: post): An array of the capabilities for this post type
map_meta_cap (boolean, default: false): Whether to use the internal default meta capability handling	hierarchical (boolean, default: false): Whether the post type is hierarchical. Allows Parent to be specified	supports (array, default: title and editor, but can support the following: title, editor, author, thumbnail [featured image, theme must support post-thumbnails], excerpt, trackbacks, custom-fields, comments, revisions, page attributes, post-formats [see Post Formats] ): An alias for calling add_post_type_support() directly
register_meta_box_cb (string, default: none): Provide a callback function that will be called when setting up the meta boxes for the edit form. Do remove_meta_box() and add_meta_box() calls in the callback	taxonomies (array, default: none): An array of registered taxonomies like category or post_tag that will be used with this post type. This can be use in lieu of calling register_taxonomy_for_object_type() directly. Custom taxonomies still need to be registered with register_taxonomy()	permalink_epmask (string, default: EP_PERMALINK): The default rewrite endpoint bitmasks
has_archive (boolean, default: false): Enables post type archives. Will use string as archive slug. Will generate the proper rewrite rules if rewrite is enabled.	rewrite (boolean/array, default: true/slug): Rewrite permalinks with this format. False to prevent rewrite	query_var (boolean/string, default: true, set to $post_type): Whether post_type is available for selection in navigation menus
can_export (boolean, default: true): Can this post_type be exported	show_in_nav_menus (boolean, default: value of public): Whether post_type is available for selection in navigation menus

*Two other arguments include _builtin and _edit_link; however, WordPress core developers recommend you don't use these when registering your custom post type.

To me, the most important arguments to set are label, labels, public (which sets publicly_queryable, exclude_from_search, show_ui, and show_in_nav_menus), description, supports, register_meta_box_cb, taxonomies, has_archive, rewrite, and capabilities.

Label

Label (a plural descriptive name for the post type marked for translation) and labels (an array of labels for this post type) are what appears on the UI (use
r interface) on the backend.

Labels

from the Codex:

Default: if empty, name is set to label value, and singular_name is set to name value

• 'name' - general name for the post type, usually plural. The same as, and overridden by $post_type_object->label
• 'singular_name' - name for one object of this post type. Defaults to value of name
• 'add_new' - the add new text. The default is Add New for both hierarchical and non-hierarchical types. When internationalizing this string, please use a gettext context matching your post type. Example: _x('Add New', 'product');
• 'add_new_item' - the add new item text. Default is Add New Post/Add New Page
• 'edit_item' - the edit item text. Default is Edit Post/Edit Page
• 'new_item' - the new item text. Default is New Post/New Page
• 'view_item' - the view item text. Default is View Post/View Page
• 'search_items' - the search items text. Default is Search Posts/Search Pages
• 'not_found' - the not found text. Default is No posts found/No pages found
• 'not_found_in_trash' - the not found in trash text. Default is No posts found in Trash/No pages found in Trash
• 'parent_item_colon' - the parent text. This string isn't used on non-hierarchical types. In hierarchical ones the default is Parent Page
• 'menu_name' - the menu name text. This string is the name to give menu items. Defaults to value of name

Public

public sets a few other parameters, which don't need to be set unless you want something different (e.g., I want a public post_type but want it unsearchable/unqueryable publicly, then public => true and publicly_queryable => false or exclude_from_search => true).

From the codex:

• 'false' - do not display a user-interface for this post type (show_ui=false), post_type queries can not be performed from the front end (publicly_queryable=false), exclude posts with this post type from search results (exclude_from_search=true), hide post_type for selection in navigation menus (show_in_nav_menus=false)
• 'true' - show_ui=true, publicly_queryable=true, exclude_from_search=false, show_in_nav_menus=true

Description

Just like category description, description could have some SEO value but doesn't inherently as of 3.1.

Supports

supports refers to the current existing post/page metaboxes: title, editor, author, thumbnail, excerpt, trackbacks, custom-fields, comments, revisions, and page-attributes.

Meta Boxes

register_meta_box_cb is the way to add more metaboxes that can be built out specifically for the custom post type.

Taxonomies

taxonomies refers to the specific taxonomies that are associated with the custom post type. So if I have a custom post type of movies, I may want my custom taxonomy of producers, stars, etc. attached to it.

Archives

has_archive enables the custom post type to have an archive.

Menu Position

While not inherently important, menu_position could be critical if you want it to appear before posts. So for convenience here are the numbers:

• 5 - below Posts
• 10 - below Media
• 15 - below Links
• 20 - below Pages
• 25 - below Comments
• 60 - below first separator
• 65 - below Plugins
• 70 - below Users
• 75 - below Tools
• 80 - below Settings
• 100  - below second separator

Rewrite

from the Codex:

$args array

• 'slug' - prepend posts with this slug - defaults to post type's name - use array('slug'=>$slug) to customize permastruct
• 'with_front' - allowing permalinks to be prepended with front base (example: if your permalink structure is /blog/, then your links will be: false->/news/, true->/blog/news/) - defaults to true
• 'feeds' - default to has_archive value
• 'pages' - defaults to true

Capabilities

Justin Tadlock wrote an excellent article regarding capabilities and capability_type: Meta capabilities for custom post types. If you want to segment out someone's capability to read, edit, and/or delete your custom post type, then read Justin's post because this argument allows you to customize and split out those capabilities.

from the Codex:

By default, seven keys are accepted as part of the capabilities array:

• edit_post, read_post, and delete_post - These three are meta capabilities, which are then generally mapped to corresponding primitive capabilities depending on the context, for example the post being edited/read/deleted and the user or role being checked. Thus these capabilities would generally not be granted directly to users or roles.
• edit_posts - Controls whether objects of this post type can be edited.
• edit_others_posts - Controls whether objects of this type owned by other users can be edited. If the post type does not support an author, then this will behave like edit_posts.
• publish_posts - Controls publishing objects of this post type.
• read_private_posts - Controls whether private objects can be read.

Note: those last four primitive capabilities are checked in core in various locations.

There are also seven other primitive capabilities which are not referenced directly in core, except in map_meta_cap(), which takes the three aforementioned meta capabilities and translates them into one or more primitive capabilities that must then be checked against the user or role, depending on the context. These additional capabilities are only used in map_meta_cap(). Thus, they are only assigned by default if the post type is registered with the 'map_meta_cap' argument set to true (default is false).

• read - Controls whether objects of this post type can be read.
• delete_posts - Controls whether objects of this post type can be deleted.
• delete_private_posts - Controls whether private objects can be deleted.
• delete_published_posts - Controls whether published objects can be deleted.
• delete_others_posts - Controls whether objects owned by other users can be can be deleted. If the post type does not support an author, then this will behave like delete_posts.
• edit_private_posts - Controls whether private objects can be edited.
• edit_published_posts - Controls whether published objects can be edited.

For example, check out this blog post: Permissions with WordPress Custom Post Types

EXAMPLES

Simple Example

A simple custom post type registration only requires a few lines of code.

[php] function wps_register_cars_cpt () {<br /> register_post_type ('wps_cars', array( 'label' => 'Cars' , 'public' => true ) );<br />}<br />add_action( 'init' , 'my_register_cpt' );<br />?>[/php]

However, it is only limited to the defaults of registering post types as you can see in the above table. However, to optimize the custom post type, you need to add a few more lines of code.

Complex Example

When registering your post type, it is a best practice to split out labels into a separate array.

[php]<br />add_action('init', 'wps_cpt_init');<br />function wps_cpt_init() {<br /> $labels= array(<br /> 'name' => _x('Cars', 'post type
general name'),<br /> 'singular_name' => _x('Car', 'post type singular name'),<br /> 'add_new' => _x('Add New', 'car'),<br /> 'add_new_item' => __('Add New Car'),<br /> 'edit_item' => __('Edit Car'),<br /> 'new_item' => __('New Car'),<br /> 'view_item' => __('View Car'),<br /> 'search_items' => __('Search Car'),<br /> 'not_found' => __('No cars found'),<br /> 'not_found_in_trash' => __('No cars found in Trash'),<br /> 'parent_item_colon' => '',<br /> 'menu_name' => 'Cars'<br /> );<br /> $args = array(<br /> 'labels' => $labels,<br /> 'public' => true,<br /> 'query_var' => true,<br /> 'rewrite' => true,<br /> 'capability_type' => 'post',<br /> 'has_archive' => true,<br /> 'hierarchical' => false,<br /> 'menu_position' => null,<br /> 'taxonomies' => array('wps_car_model','wps_car_color'),<br /> 'register_meta_box_cb' => 'add_wps_metaboxes',<br /> 'supports' => array('title','editor','author','thumbnail','excerpt','trackbacks','custom-fields','comments','revisions')<br /> );<br /> register_post_type( 'wps_cars' , $args );<br />}<br />[/php]

Is there a right way and a wrong way to using Custom Post Types? I am not sure. To me, it entirely depends on the amount of work one wants to put into the development of the custom post type. Custom Taxonomies and Post Formats solves many issues, especially for Theme developers, that people were trying to solve via custom post types.

Always ask yourself these questions (some from Taylor D. Dewey)

1. Do I need discrete categorical or tag-type information applied to this information?
2. Is this a variation of a blog post or a page?
3. Do I need to display traditional pages, blog posts, and a 3rd completely unrelated type of information?
4. Can my data type fit within the existing schema of pages and posts?
5. What is my goal/objective that I am trying to accomplish?
6. Can my goal/objective be accomplished through the use of post formats?
7. Can my goal/objective be accomplished through the use of custom taxonomies?
8. Do I need to use custom taxonomies?

If you want to make something that shows up in the normal feeds, or shows up mixed into the blog, or shows up using the normal templates, or basically is a "Post" in the sense of the existing WordPress posts in any way whatsoever, then you may not want to use a Custom Post Type.

Custom Post Types, by default, are custom, and as such should be something different entirely. Posts appear in the blog and feeds. Pages are typically static and have their own hierarchical structure. Custom post types are defined by the developer (and in my opinion, by the content) and is NOT a post or a page. If you want a way to separate one "type" of post from another, then custom taxonomies or post formats are the best way to do this.

The confusion stems from the naming of custom post types. If custom post types were called custom content types, I wonder if we would be having this discussion. Regardless, custom post types are content types. They are not different types of posts. Taxonomies allow for the organization and separation of the same types of content into any sort of taxonomy whether hierarchical or not. Post formats allow and encourage different formatting of posts.

Recently, one individual ranted about custom post types not being part of the feeds by default. To me and many others, this is a good thing because custom post types are content types. While some content types are designed for public viewing, they do not belong to the feed per se. For example, if I have a FAQ or event post type, each "post" to those content types do not belong to my feed. Yet on the other hand, if I wanted to make podcast a custom post type, I have to do the work to link it to the feed, have it appear on the blog, create a template to show multiple entries, etc. Could there be some benefit of a podcast custom post type? Yes, but it includes doing work that has already been done. And as such, why would you want to reinvent the wheel? If my goal or objective is user experience, then that might be worth some extra work. I am not sure. That's for you to decide. However, that was not what WordPress has set out to accomplish via custom post types. Yet, some of us want to reinvent the wheel and have no problem doing so. Jason's point is that we should not have to reinvent the wheel and that custom post types should come like posts by default. While I disagree with Jason to a degree, I do see his point and have to admit that I agree with him to a degree.

Otto states that "There’s no code in there [WordPress core] to do that [e.g., have custom post types appear in the blog/feed], and there’s very likely not going to be [in the WordPress core]." Though I don't believe WordPress should write the code to make everything happen as that could be a massive undertaking, I do believe that WordPress should incorporate an argument for feed/loop in the register_post_type that could be boolean types if set to true would add the custom post type into the "blog" and feed. The code to incorporate the custom post type into a blog is fairly simple as Justin Tadlock has demonstrated:
[php]
add_filter( 'pre_get_posts' , 'wps_add_my_cpt' );
function wps_add_my_cpt() {
if ( is_home() && false == $query->query_vars['suppress_filters'] )
$query->set( 'post_type' , 'array( 'post' , 'wps_cars' );
return $query;
}[/php]

And showing the post types in the feed is just as easy!
[php]
add_filter( 'pre_get_posts' , 'wps_add_my_cpt' );
function wps_add_my_cpt() {
if ( ( is_home() && false == $query->query_vars['suppress_filters'] ) || is_feed() )
$query->set( 'post_type' , 'array( 'post' , 'wps_cars' );
return $query;
}[/php]

Therefore, adding a simple if-then statement with these filters should not be a problem.

However, as it currently stands and as Otto simply stated, "Separation of content type in the admin panel is not a good reason to create a whole new “type”. Not if what you really need is to separate existing posts by some other factor. That’s what taxonomies [and post formats] are explicitly designed for." While I agree with Otto to a degree, I also highly value user experience. So would separation of content type in the admin panel to increase user experience be a good enough reason to create a whole new post type? Again, that's for the developer/designer to decide. As for WordPress, right now, it's not.

This is the new WordPress Soup: Custom Post Types, Post Formats, Custom Taxonomies, and Custom Fields/Meta Boxes. First and foremost, since we have already talked about what custom post types are, let's define the other two: post formats and custom taxonomies.

Post Formats

Post formats are not post types, that is, they are not content types. Instead, they are varying types of posts. They are posts with varying formatting. For example, consider the following:

• a shared link should have a link as its focus.
• a video should have a video as its focus, maybe its only content
• an image should have an image as its focus, maybe again, its only content
• a quote should have a quote as its focus, maybe its only content
• Etc.

As Mark Jaquith states:

A Post Format is a formatting designation made to a post. For example, a post could be a short “aside,” or a Kottke.org-style link post, or a video post, or a photo gallery post. The data you input might be slightly different — video post should contain a video, an aside should probably not be very long, a link post should have a link. And the way that the post is displayed on the site might be very different — an aside will typically be displayed without a title, a link post may have the title point to the link. A video post may be wider, or have social sharing buttons auto-appended. But they’re all still posts. They still show up in your feed, and you still find them in the Posts section of the WordPress backend.

There are two major differences between custom post types and post formats. They are:

1. Post formats will appear in the main RSS. Custom post types do not appear in the RSS feed by default without further coding (though in my opinion this should be part of the registration coding as it is with searching).
2. Post formats are a WordPress "standardized convention." In other words, instead of using categories to customize output and display (that may or may not be supported across themes/frameworks), post formats provides a standard method of doing this.

Simply, think Tumblr! StudioPress's Tapestry Child Theme makes good use of Post Formats.

As far as WordPress is concerned, there are ONLY 10 Post Formats available to users/theme developers. They are:

1. standard - regular post
2. aside - Typically styled without a title. Similar to a Facebook note update.
3. gallery - A gallery of images. Post will likely contain a gallery shortcode and will have image attachments.
4. link - A link to another site.
5. image - A single image.
6. quote - A quotation. Probably will contain a blockquote holding the quote content. Alternatively, the quote may be just the content, with the source/author being the title.
7. status - A short status update, similar to a Twitter status update.
8. video - A single video.
9. audio - An audio file. Could be used for Podcasting.
10. chat - A chat transcript

Now, just like thumbnail images, post formats must be activated by the theme.

[php]add_theme_support( 'post-formats' , array( 'aside' , 'chat' , 'gallery' , 'image' , 'link' , 'quote' , 'status' , 'video' , 'audio' ) );[/php]

To style post formats, use the following new CSS classes:

Standard: Normal CSS
Aside: .format-aside {}
Audio: .format-audio {}
Chat: .format-chat {}
Gallery: .format-gallery {}
Image: .format-image {}
Link: .format-link {}
Quote: .format-quote {}
Status: .format-status {}
Video: .format-video {}

Custom Taxonomies

Think Categories and Tags. These both represent two types of taxonomies: hierarchical, where terms can have a parent-child relationship (e.g.,categories) and non-hierarchical, where all terms are equal (e.g., tags). Custom taxonomies give you the ability to name and create taxonomies that act like Tags and Categories but are named whatever you'd like to name them.

Other built-in taxonomies include Link Category and Nav Menu. So what are some custom taxonomies? These can be determined by custom post types and can be whatever you need them to be; for example, an employee custom post type could use an employee departments hierarchical taxonomy. Another example could be a movie custom post type utilizing multiple taxonomies of genre, director, stars/actors, etc. (More information forthcoming...)

Custom Fields and Meta Boxes

These are designated areas to input information on a per post/custom post (or content entry) basis. Generally speaking, if the Title, Editor, etc. that is found on a post won't do what you want it to do with the content, then most people add custom fields that creates an easy way to input content as well as display the content. Custom Meta Boxes and Custom Fields are sets of additional editable fields that may be added to any post type, whether page, post, or a custom post type. The custom fields can be used to store any sort of content/data that you want. They are often single line input boxes, checkboxes, dropdown boxes, paragraph text areas, radio buttons, etc. There will be more on this later as Custom Meta Boxes and Custom Fields are usually extremely important to Custom Post Types. (More information forthcoming...)

Summary

So, in short, custom post types are content types for custom storing with custom displays on the backend and front end. Post formats are types or variations of displaying content on the front end only coming with a standardize set of 10 choices. Custom taxonomies are terms, whether hierarchical or not, that are used for organizing content. Custom Meta Boxes and Fields are designated areas to add more information beyond the standard title, editor, etc. (which are displayed via built-in meta boxes).

More Information/Further Reading

Post Formats Links

• Otto: Post types and formats and taxonomies, oh my!
• Andrew Nacin: On standardized post formats
• WPBeginner: What, Whys, and How to’s of Post Formats in WordPress 3.1
• Mark Jaquith: Post Formats vs. Custom Post Types
• Lisa Sabin-Wilson: WordPress 3.1 Post Formats Reference
• WordCast: WordPress Post Formats Tutorial: Add Tumblr Style Features To Your Blog with WordPress 3.1
• WP Engineer: Post Formats – More Creative Ways For A Theme
• Flashing Cursor: Intro to Post Formats in WordPress 3.1

Custom Taxonomies Links

• Tammy Hart: Custom Post Types and Taxonomies
• net tuts+: Introducing WordPress 3 Custom Taxonomies
• 1WD.CO: The Essential Guide to WordPress 3.0 Custom Taxonomies
• WP Dad: A Short Introduction to WordPress 3.0 for Beginners

Other

• WordPress Theming: Custom Post Type Resources

It's really funny that the results of a basic search on the internet for the benefits of custom post types is scarce on the benefits or the advantages of custom post types. To me and I believe to the whole WordPress community, the benefits of custom post types are dramatic! The benefits and advantages of custom post types are innumerable and exponential. (If you don't know what Custom Post Types are, see my previous post: Understanding WordPress Custom Post Types: What Are Custom Post Types?.)

So here are five benefits and advantages of using custom post types or rather, here are five reasons why you should use custom post types:

1. Custom display of content: custom post types allow for content to be entered and displayed in a custom manner that is content-centered and content-focused.
2. Hide content from default queries: It's not that you are hiding content per se; however, out of the box, custom post types are not included in the query further customizing the ability to organize and present the content the way you want. Without additional coding, custom post types are not included in the default queries. Furthermore, the customization options allowed in registering custom post types further increases the beauty and power of custom post types by making them non-public and non-queryable.
3. Ability to manage content: on the backend, custom post types streamline writing and organization
4. Improved usability: simply it is quite complex to tell a client, "To post a podcast, you must do A, B, C, and D. To post a blog post, you must do A, B, and C." Custom post types allow you to create one singular process that makes sense to the non-programmer and non-power user.
5. Increases productivity and efficiency: now
6. Increases site security: it will eliminate third party plugins further strengthening your security (or rather eliminating dependency on a third party that could potentially open a vulnerability).

So let's think about this for a minute. How does custom post types increase productivity?

As Konstantin points out, consider this scenario:

For instance, why should the Edit Post page contain the ability to attach an audio file if it won’t be used 50% of the time? Or why would Quotes contain post revisions? Chats and Video posts wouldn’t require image posting, right? This way you can talk to your client or content manager in a certain way:

John, could you please add a new Podcast? Here’s the MP3 file.

Instead of

John, I need you to add this MP3 file as a Podcast – please add a new post, then in the box on the right you should pick that your post type is a Podcast, then a little bit lower in the next box you should upload this audio file, and also please make sure that you check the Podcasts category before you publish.

No, John, don’t touch the Video box, we use that for video posts. No, leave the custom fields as they are, you should never touch that area.

So, now you don't have to rely on categories. You don't have to filter categories here or there to get the pages that you want. Posting becomes simple and easy. Displaying content becomes streamlined and custom. The backend can be further customized. No more wasted space in the database or the post page. No more wasted landscape in the backend. No need to explain complicated custom fields. Everything becomes straight forward and simple.

Simply, custom post types help you CUSTOMIZE and ORGANIZE your CONTENT in order to PRESENT it in a better manner (than simply high-jacking and even abusing categories or having to explain custom fields again and again). Before the popularization and the simplification of custom post types, developers were stuck with using custom fields and categories and had to give detailed, robust instructions which often times led to confusion (and possibly the breaking of the site altogether). Not only can custom post types be wrapped around your content, it is molded to your data, your needs, and your goals, whatever they may be. It will make things easier to manage, create, edit, etc. It will increase productivity, efficiency, and even usability.

What benefits or advantages do you see about custom post types?