By default WordPress comes with a few post types already defined. But the two most obvious ones being pages and posts. The biggest difference between these two post types is down to how they are displayed by WordPress.
WordPress Pages.
Pages are generally used for content that’s fairly static; contact forms, about us, are the ideal content for pages. Pages can’t be assigned categories or tags, but are hierarchical, so one page can be the parent of another. Pages can be assigned particular templates, so a php template can be designed to show your pages content however you’d like.
WordPress Posts.
Posts are usually displayed chronologically with the newest or latest post displayed first. Posts can be assigned categories and tags, for example in a blog you could have a news categories, a tutorial category and an article category. Users can then view your posts that you’ve grouped together into categories.
Custom Post Types.
Before custom post types came along if you wanted to create a new type of content you had to make the decision on how this content fits within WordPress. Can the content be fitted into the standard blog posts, perhaps by assigning a new category to it? Or if the content isn’t date depandant then perhaps a page is the better choice. With custom post types you’re no longer restricted to these two types of content. You can easily define your own post types that exactly match your new content type, this could be products in an e-commerce site, a portfolio of completed projects or a diary of upcoming events.
Your new custom post type, along with all of the default WordPress post types; posts, pages, attachment, revision and navigation menu are all stored in the same database table, wp_posts.
Creating a new custom post type.
Once you have defined you new custom post type a new menu item will show up in the WordPress admin menu, letting you add your new content in pretty much the same way as you’re used to with posts and pages.
Getting started with your first custom post type.
There’s a lot of options available when defining custom post types, so for the sake simplicity we’ll deliberately keep our example light on options. Our custom post type is going to called ‘Support’ and is going to be used to hold support articles for our users.
In this article we’ll be adding our new code directly to our themes’ functions.php file, however for transportability between themes this would be better packaged up as a new plugin. In a later article we’ll also add a few templates to our themes folder to handle displaying our new content more precisely.
Ready? so open up your themes’ functions.php file and add the following code.
/* Create custom post type support */
add_action('init', 'post_type_support');
function post_type_support() {
register_post_type(
'support',
array(
'labels' => array(
'name' => __( 'Support' ),
'singular_name' => __( 'Support' ),
'add_new' => 'Add New',
'add_new_item' => 'Add New Support Article',
'edit' => 'Edit',
'edit_item' => 'Edit Support Article',
'new_item' => 'New Support Article',
'view' => 'View',
'view_item' => 'View Support Article',
'search_items' => 'Search Support Articles',
'not_found' => 'No Support Articles found',
'not_found_in_trash' => 'No Support Articles found in Trash',
'parent' => 'Parent Support Article'
),
'public' => true,
'supports' => array(
'title',
'editor',
'author',
'excerpt',
)
)
);
}
So the first bit adds an action, namely our function ‘post_type_support’ that runs on ‘init’, which is when WordPress has finished loading but before any headers are sent.
The next bit is a function that defines our new custom post type, in this case called support. The register_post_type function takes two arguments: a unique name, then an array that makes up the properties of our new post type, which can be made up of strings or further arrays. The labels array defines how the custom post type is referred to in the admin screens, looking down the list it should make sense to you. After that a couple more arguments define whether the custom post type is publically viewable, is not hierarchical (pages are hierarchical) and which meta boxes will be available in the post editing screens; title, editor, author etc.
Save this in your functions.php and head back to the admin screen of your WordPress installation, you should notice a new menu item on the left for our new custom post type. You can start adding articles to it right away, but first let’s register a custom taxonomy to help organise our articles into meaningful groups.
For the full list of all arguments when defining custom post type refer to the WordPress codex here http://codex.wordpress.org/Function_Reference/register_post_type
Custom Taxonomies
Our custom taxonomy is going to be called subjects. So subjects are to support as categories are to posts, make sense? This next bit of code creates our new subject taxonomy.
/* Create our custom taxonomy */
add_action('init', 'support_series_tax');
function support_series_tax() {
register_taxonomy(
'subject',
'support',
array(
'labels' => array(
'name' => __( 'Subjects' ),
'singular_name' => __( 'Subject' ),
'search_items' => __( 'Search Subjects' ),
'all_items' => __( 'All Subjects' ),
'parent_item' => __( 'Parent Subject' ),
'parent_item_colon' => __( 'Parent Subject:' ),
'edit_item' => __( 'Edit Subject' ),
'update_item' => __( 'Update Subject' ),
'add_new_item' => __( 'Add New Subject' ),
'new_item_name' => __( 'New Subject Name' ),
'menu_name' => __( 'Subjects' ),
),
'hierarchical' => true,
)
);
}
So with this also added to our functions.php file you should now see subjects in the support menu section in the admin area. Yet again the bulk of this function is the labels array which defines WordPress will refer to ‘Subject’ in the admin screens. Our custom taxonomy is going to behave just as categories do in regular posts, so we’ve set hierarchical to true so subjects can have parent subjects.
You can find the full list of arguments in the WordPress codex here http://codex.wordpress.org/Function_Reference/register_taxonomy