Why does a custom post type need the ''hierarchical' args setting?

Question

I'm struggling with understanding some things about CPTs and and could do with some help. I can see that taxonomies often need to be hierarchical, but can't see how/when a custom post type would be?

i.e I have a CPT called 'projects'. There is a taxonomy registered for this posttype called 'fields'. Under 'fields' I have lots of sub-items like:

• 'Documentaries'
• 'Documentaries' > 'Self Commisions'
• 'Documentaries' > 'Classic'
• 'Corporate'
• 'Corporate' > 'Digital Marketing'
• etc...

So to view a project in 'Documentaries' > 'Classic' I use this URL: mydomain.com/field/classic/

This is where I actually have about 30 questions :) but will just ask the two most pressing:

1. Why and how would the 'projects' CPT ever be hierarchical?
2. Is it possible to view items in the 'classic' field like so: mydomain.com/projects/classic (mydomain.com/projects shows all items, but drilling any further breaks it)

Any and all help appreciated, I've spent about 3 hours playing with this and reading and can't get my head around it!

Thanks!

Below is my (cropped) code for reference:

function register_cpt_projects() {
$labels = array(
    'name' => _x('Projects', 'projects'),
    // all other labels etc..
);

$args = array(
    'labels' => $labels,
    'hierarchical' => true,
    'supports' => array('title', 'editor', 'author', 'thumbnail'),
    'taxonomies' => array('field'),
    'public' => true,
    'show_ui' => true,
    'show_in_menu' => true,
    'show_in_nav_menus' => true,
    'publicly_queryable' => true,
    'exclude_from_search' => false,
    'has_archive' => true,
    'query_var' => true,
    'can_export' => true,
    'rewrite' => true,
    'capability_type' => 'post'
);
register_post_type('projects', $args);
}

add_action('init', 'register_cpt_projects');

function create_projects_tax(){
    register_taxonomy('field', 'projects', array(
       'hierarchical' => true,
       'label' => 'Fields'
    ));
}
add_action('init', 'create_projects_tax');

Answer 1

When you have two content objects with a similar interface or shared properties, you have a good candidate for hierarchical post types.

Take places as an example (see this answer):

• Asia
• Europe
  • Germany
    • Berlin
  • Austria
    • Vienna

Each place has similar meta data: population, geo coordinates, spoken languages. You just can reuse the same interface.

Plus, if you create a separate custom post type for each kind of place you’ll run into WordPress’ missing post-to-post relationship table.

Answer 2

A custom post type only needs the hierarchical setting if you want the post type to behave like pages.

If you want to be able to choose a parent and have the menu order metabox you also need to add 'page-attributes' to the supports array.

The hierarchical argument also allows you to treat hierarchical post types different than others by using the is_post_type_hierarchical() conditional tag. It supports post object, post type name, or post ID as its single parameter.

Is it possible to view items in the 'classic' field like so: mydomain.com/projects/classic (mydomain.com/projects shows all items, but drilling any further breaks it)

You can use the rewrite argument to define how single post type urls appear:

slug: The slug you’d like to prefix your posts with.
with_front: Whether your post type should use the front base from your permalink settings.

'rewrite' => array( 'slug' => 'classic', 'with_front' => false ),

would make your urls for single project posts look like:

yoursite.com/classic/post-name

If you want to make your archive urls: mydomain.com/projects/classic you will need to apply similar rewrite rules to your register_taxonomy arguments.

You would need to set the rewrite slug to projects and with_front to false. Also to note is that the register_taxonomy rewrite array also supports: 'hierarchical' - true or false allow hierarchical urls This allows you to use the full hierarchy on the taxonomy terms in your urls: