Hierarchy 1.0 is Here!

Hierarchy is now at version 1.0! Check it out and find out more about the changes that went into it.

A long time ago I wrote about a plugin I built that I’ve used on every client site since doing so. It solved a problem that exists only if you use WordPress in a certain way, but a lot of people do. Not everyone sees it as a problem, but my brain does. Here’s my overview:

WordPress’ Custom Post Types were pivotal when introduced, and they’ve proven to be an integral reason for the success of the platform. They allow us to set up specially designed buckets for our content, which facilitates content management to a much greater degree. For me the problem arises primarily due to CPT edit links being injected into the main WordPress Admin Menu. Many of my CPTs are designed to be nested among the content of the site (which is structured primarily by Pages) not at a top level.

Take for example the following site for a small local business. They have a standard set of Pages to house their content, and there are a few Custom Post Types as well. There’s a CPT for their Locations, another for their staff, a third for a Knowledge Base, and one more for their Portfolio.

Now let’s take a look at how the Pages are set up and how their main site navigation looks.

The Menu powering the navigation in the header is our desired structure. The Pages in WordPress are somewhat able to replicate that structure, but there are some caveats:

• There is a CPT for People which contains entries for each staff member. On the main Team page the client wants to include some custom content, so using a CPT archive ('has_archive' => true) does not apply.
• We want our URLs for team members to include the Team Page slug, which is a child of About Us. This is possible using the rewrite parameter when registering our CPT. However there is a disconnect with People being a top level WordPress Admin Menu entry. If People are part of the Team page in the About Us section of the site, it doesn’t seem applicable to have a link in the main Admin Menu.
• There is a similar issue with Locations. This CPT will be using it’s own archive template because we don’t need any extra information on the Locations index page, but it should be a ‘child’ of the About Us section of the site. A link in the main Admin Menu is a bit disorienting.
• The Knowledge Base is a hierarchical CPT that is placed within the Support section of the site, so the same issue occurs with this Admin Menu entry.
• The Blog page is being used as the Posts page as per the Settings > Reading > Front page displays setting, yet we’re able to see it in the Pages listing and edit it, but editing it results in no change on the website.

These are the circumstances Hierarchy aims to modify.

Using Hierarchy to better facilitate content management

Hierarchy aims to better organize Custom Post Types by integrating them within the site structure as defined by your Pages. That way, editing Custom Post Type content feels like consuming it on the front end. Links are contextual as per the way you’ve set up your Pages and registered your Custom Post Types. Using the example site from above, here is what the WordPress admin area looks like with Hierarchy activated:

It may not look like it at first, but a lot has changed! First have a look at the Admin Menu itself. The Posts, Pages, and Custom Post Type management links have all been removed and gathered under a ‘Content’ Menu entry. Viewing the Content of the site gives you a hierarchical overview of all the content on your site, not just one post type.

Existing users of Hierarchy will notice a couple of nice additions to version 1.0: Dashicons support and also a button up top to add a new Page.

Hierarchy’s setup aims to be as streamlined as possible, and piggybacks methods we’re already used to. Pages are the underlying structure of every WordPress site and Hierarchy carries that a bit further. There’s an abstraction between setting the Page Order in the WordPress admin, and how you choose to include it in a Menu. Since the code has no control over how Menus are set up, Hierarchy uses the Page Order model to allow for it’s configuration:

The primary function of the Hierarchy settings screen is to specify how your Custom Post types are integrated into your Page hierarchy. Hierarchy has some smarts that will automatically define where CPTs need to be children of Pages (due to a matching rewrite slug) but you can fine tune the placement by setting the Order for each CPT. Hierarchy’s CPT Order is the same as WordPress’ Page Order, so keep that in mind as you’re setting values.

There are other options you have when configuring your CPTs as well:

• Prevent New: when checked, all of the ‘Add New’ links will be removed for this post type
• Show Entries: when checked, the entries for this post type will be output as well
• Omit: when checked, this post type will not be included in the Hierarchy

When Show Entries is enabled, you’ll get something like this:

Further down the page you have control over the pagination of Hierarchy itself, so if you have a large site you can break it up into multiple pages for easier management. At the bottom you can choose to remove post type links from the Admin Menu. This is opt-in so by default all of your CPT links will remain in the Admin Menu because from time to time it makes perfect sense for CPT links to be top-level.

Once Hierarchy has been configured properly, the Content menu created by Hierarchy will gather everything together into an all-encompassing hierarchical view of all your content. Links to manage the content have been added as WordPress does in it’s post type index page, and hovering each entry brings in applicable, edit, view, and taxonomy links where applicable:

In this screenshot another aspect of Hierarchy is unveiled: it automatically detects which Page you have set as the Posts page in Settings > Reading > Front page displays and instead of including a link to the page instead includes links for your Posts. If you haven’t set this setting the Posts post type will be included as any other Custom Post Type.

Hierarchy has proven essential for me

Hierarchy is one of those things I built and two years later I realized it was ingrained in my process and I needed to tackle some long standing issues I had with the code base. To be honest the entire thing was refactored nearly to the level of an entire rewrite. The code smell was out of hand and I wanted to structure things differently. I’m really pleased with the way the refactor came out.

It’s now ready for me to begin iterating on additional features I have planned, but that’s where you come in. I’d love to hear some feedback on Hierarchy, but to be honest I’m surprised at the lack of adoption. Am I crazy in feeling something like this is essential, particularly for client sites? I know it’s a big education effort to even explain what Hierarchy does, but I’m trying to make the plugin page on .org as digestible as possible. Unfortunately to explain all of the nuances of Hierarchy it requires either an extensive explanation like this, or for you to actually sit down and activate it on one of your sites.

As with all my plugins, Hierarchy is on GitHub. I’d love to collaborate and make Hierarchy a utility in everyone’s tool belt. I really hope you like the updates, I’m wicked psyched about it.