- About the author
- Jonathan Christopher
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.
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:
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:
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:
With these settings in place, we get a complete, hierarchical view of our entire site at once:
This really scratches an itch I’ve had for some time now, and I’m super glad that it’s finally been released.
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
<?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
true, a populated Team section would look something like this:
Other things to note:
truethere will be a View link present in the actions row, it will be omitted otherwise
Here is the Team row on hover:
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.
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:
As you can see in the screenshot, we've still got a problem though.
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.
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.
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.
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.