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

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:

Read More
  • ‘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');

Related posts

Leave a Reply

2 comments

  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.

  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: