Introducing Hierarchy: Even More CMS for WordPress

Published 4 years 10 months ago on January 5, 2012 — 6 min read

A long standing (for what reason I’ve yet to understand) debate surrounding WordPress is whether or not it’s a “true” content management system versus a blogging platform. Nomenclature aside, I’ve been “using WordPress as a CMS” for years and will always call it a CMS because: it manages content. As much of a blanket statement that is, to argue about it seems moot.

That said, as much as I love WordPress I do have some qualms about it, and everything can be summed up in three words: Custom Post Types. I’ve had a love/hate relationship with Custom Post Types for some time now, even back to before they were Custom Post Types. The problem can be outlined by taking a high level view over how you manage WordPress content.

At the root there are Pages. Pages are the skeleton to your site, they control the URL structure and give your content form. Then there are Posts, most often used to power the Blog of your site. Fact of the matter is, though, unless your Blog is the main page of your site, editing this content in two completely separate places doesn’t really make sense.

I completely understand the situation though, given WordPress’ roots, but I haven’t built a blog-focused site in years. One of the very first options I change is under Settings > Reading and redefine Front page displays, defining my Front page as a Home page I’ve created, and the Posts page as a Blog page I’ve created.

When I’m in this situation, I need to now have a Page view that structures the site in it’s fully organized glory, but then there’s this Blog Page that links to an edit screen that doesn’t power anything because WordPress under the hood us grabbing your Posts, which is in a completely different menu area.

This problem becomes compounded exponentially when Custom Post Types come into play. Now you’ve got a Page tree, Posts in the main sidebar that control the Blog section, and any number of Custom Post Types also in the main sidebar that power various (likely internal) sections of the site.

I hate explaining this to clients and I’ve wanted to do something about it for a long time now. So I have.

Introducing Hierarchy

In an ideal world, CPT editing would be directly integrated within your Pages structure (as Pages are the basis of your URL structure) and not need a dedicated sidebar menu entry. That’s the short version of exactly what Hierarchy does.

Hierarchy allows you to (optionally) remove CPT items from the Admin Menu and integrate them within a Page-like hierarchical view labeled “Content”. Take for example this sample WordPress site. It’s got a mix of Pages, Posts, and Custom Post Types working together to give an overview of a small design business:

Screenshot of the WordPress admin

The Page view gives us an overview of the site structure, but to manage the Blog or Portfolio is very disjointed with the action links being in the Admin Menu itself. When we activate Hierarchy, we see something like this:

Screenshot of the WordPress admin

In my opinion, this is much easier to work with in comparison, but it can be even better. All of the CPT entries remain in the Admin Menu, so Hierarchy will let you hide them. In addition, a couple seem a bit out of place, so Hierarchy will let you provide a menu_order for your CPT entry as well:

Screenshot of the WordPress admin

With these settings in place, we get a complete, hierarchical view of our entire site at once:

Screenshot of the WordPress admin

This really scratches an itch I’ve had for some time now, and I’m super glad that it’s finally been released.

Positioning your CPTs

It seems like a number of people are unfamiliar with the fact that you can give your custom post types a nested slug that falls below an existing Page. It’s as easy as defining the rewrite_slug parameter when registering your post type. That (in combination with the Order you set) is how Hierarchy knows where to place the CPT entry. Referencing our example site, we see that Team is a “child” CPT of the About page.

Our About Page has a slug of about and our Team CPT has a rewrite_slug of about/team:

<?php
register_post_type( 
    'team',
    array(
        'label'             => 'Team',
        'description'       => '',
        'public'            => true,
        'show_ui'           => true,
        'show_in_menu'      => true,
        'capability_type'   => 'page',
        'hierarchical'      => false,
        'rewrite' => array(
            'slug'          => 'about/team'
            ),
        'query_var'         => true,
        'has_archive'       => true,
        'supports' => array(
            'title',
            'editor'
            )
    )
); ?>

You'll also notice that hierarchical has been set to false, that controls whether or not the CPT entries are included within the Hierarchy as well. If hierarchical is true, a populated Team section would look something like this:

Screenshot of the WordPress Admin

Other things to note:

  • The actions row includes a link to add a new CPT entry
  • If has_archive is true there will be a View link present in the actions row, it will be omitted otherwise
  • The actions row has an Edit link that will bring you to the standard WordPress CPT table edit listing
  • Clicking the CPT name will bring you to the standard WordPress CPT table edit listing

Here is the Team row on hover:

Screenshot of the WordPress admin

Other things have been customized for CPT entries in Hierarchy including respect for a custom menu_icon you have set and hiding the Author, Comments, and Date columns as they're not applicable.

Handling taxonomies

Originally I had made a bigger issue out of taxonomies than it needed to be. When Hierarchy is building the content tree, it checks to see if any taxonomies are associated with the entry at hand. If so, links to manage those taxonomies are included in the action row:

Screenshot of the WordPress admin

As you can see in the screenshot, we've still got a problem though.

The Blog issue

As I had mentioned, another confusing issue comes up when you set Settings > Reading and redefine the Front page displays setting. In the example above, we've essentially got a duplicated link because this option hasn't been set yet, let's change that.

Screenshot of the WordPress admin

When you change the Posts page in Front page displays, Hierarchy takes that into account and merges the two, essentially hiding the (not needed) Blog Page, and replaces it with your Posts.

Screenshot of the WordPress admin

It does it in a smart way though, it'll use the Title you've set for your designated Posts page as the post type name of "Posts" doesn't really make sense anymore.

That's Hierarchy

I sincerely hope you enjoy Hierarchy and that it makes the lives of your clients easier, I know it will mine. I've been wanting to build this plugin for a year or two now, and although it's very new, I'd love to hear your thoughts and feature suggestions! WordPress just took another step toward even better content management.

Copyright © 2006—2016 Jonathan Christopher