While custom taxonomies provide a powerful way to organize posts, sometimes that organization just isn't enough. For a blogger, using posts for movie and book reviews as well as slice-of-life vignettes might suffice, but posts and pages can be too limiting a framework for more complex sites.
WordPress 3.0 provides methods of creating whole new content types. New types can be hierarchical, like pages, or non-hierarchical, like posts. As you create the new types, you can choose which attributes (revisions, thumbnails, etc.) they support. And, of course, you can assign taxonomies to your custom types.
■ Note: Custom content types are also referred to as custom post types throughout the WordPress documentation, since posts are the underlying basis for all other content types.
Let's consider a real-world scenario: a university department site containing information about specific courses as well as news updates (the blog) and informational pages (hours and location, a staff directory, etc.). Without custom content types, the choice lies between posts and pages. Since the office would like to publish a feed of all the honors courses available (and individual feeds for each college), they have elected to use posts to store the course information. Figure 12-11 shows a typical course post.
You can make this office's workflow a lot better using a custom content type for the courses. In WordPress 3.0, creating new content types is as easy as creating new taxonomies. The register_post_type() function looks an awful lot like register_taxonomy(), and many of its attributes work the same way. Listing 12-11 shows a sample content type with all the possible arguments.
Listing 12-11. Creating a new content type register_post_type( 'mytype', array(
'supports' => array( 'title', 'editor', ' author' , 'excerpts', 'custom-fields', 'revisions', 'thumbnail')
register_taxonomy_for_object_type('post-tag', 'mytype'); ?>
As with taxonomies, the post types are created with a handle and an array of attributes. Here are all of the possible attributes:
• labels: an array containing the names of the content type in their plural ('name') and singular ('singular_name') forms.
• description: a short description of the content type. Empty by default.
• public: whether this content type should be shown in the admin screens. False (hidden) by default.
• exclude_from_search: whether content of this post type should be excluded from search results. By default, inherits the value of public.
• publicly_queryable: whether queries can be performed using the post_type argument. By default, inherits the value of public.
show_ui: whether Edit and Add New screens should be added for this post type. By default, inherits the value of public.
• inherit_type: if you would like the new type to use the capabilities of an existing type, use this argument to set it.
• capability_type: content type for read_, edit_, and delete_ capabilities. Post is the default type used if no other is specified. You can use this argument to create a whole new set of capabilities specific to the new content type (e.g. 'course').
• capabilities: an array of capabilities ('edit_post,' 'delete_post,' 'publish_posts'). If you created a new capability_type, these values will default to the standard post capabilities with the name of your content type substituted for 'post' (e.g. 'edit_course,' 'delete_course,' 'publish_courses').
• hierarchical: whether the post type is hierarchical (page-like). False (post-like) by default.
• Supports: as a substitute for calling the add_post_type_support() function, list supported features here. Defaults to none. The possible features are:
o author: the user writing the custom entry o title: whether this content type includes a title o editor: whether the visual/HTML content textarea and media uploader should be used o excerpts: whether the excerpts field should be used o thumbnail: whether this content type should include image thumbnails o comments: whether comments will be accepted for this content type o trackbacks: whether trackbacks will be accepted for this content type o custom-fields: whether the Custom Fields box will be shown and custom fields automatically saved.
o revisions: whether revisions will be stored and displayed.
o page-attributes: the Page Attributes box, containing the parent, template, and menu order options.
• register_meta_box_cb: the name of a callback function that will set up any custom meta boxes for the edit screens. This function should contain any remove_meta_box() and add_meta_box() calls.
• Taxonomies: an array of taxonomy names that will be used by the content type. Default is none. You can register taxonomies later with register_taxonomy() or register_taxonomy_for_object_type().
Note that public is true by default for taxonomies but is false by default for post types. The query_vars, rewrite, and show_ui attributes all inherit from public, so be sure to set public to true (or turn on each of those items individually).
Was this article helpful?