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:
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.
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:
Other things to note:
- The actions row includes a link to add a new CPT entry
- If
has_archiveistruethere 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:
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:
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.
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.
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.
Comments
Wow. Intriguing. Nicely done.
I’m really torn about this approach. We haven’t built a blog specific site in ages as well. But our clients really like having everything in the main menu approach. I like the idea of having the hierarchy within a page but was thinking about doing something similar but just define all the CPTs and pages within 1 fly out menu now that 3.3 is out. Definitely going to play around with it. And kudos on your release.
Nice work! This is definitely something I will use. Thank you.
That’s a great idea..
we’ll totally be using this!
I’ve been DYING for something like this. Every project always has “featured items” for the home page or a “portfolio” or “case studies.” Things that should be CPT’s, but should also appear under the main page hierarchy.
Brilliant.
Interesting. I’m using Custom Post Types on every WordPress project so might have to play with this on the next one.
pretty slick bro! Can imagine using this with pods 2 to extend CPT’s and make a killer CMS. Awsome work!
Absolutely amazing, fantastic and wonderful. Will definitely be using in next WP project. Thank you.
It’s a nice approach, but for clients I usually use http://wordpress.org/extend/plugins/cms-tree-page-view/ wich is more intuitive to manage pages than the standard view. Probably it doesn’t integrate with Hierarchy…
This is a really interesting idea, and it’s great to see plugins like this.
I can immediately see a couple of problems though, and depending on how ‘custom’ your custom post types are it might mean that Hierarchy just won’t work in some situations.
For example, you immediately lose your custom admin columns. Three custom post types might have three entirely different sets of admin columns. There’s not going to be an elegant way to get all those different custom columns onto one screen, especially if they’re filterable or sortable.
Once you have a handful of custom post types and more than a dozen or so posts in each, plus several pages, this screen will surely become even more unmanagable than the ‘Pages’ screen becomes when you have many pages. You’ll end up back where we were before we had custom post types and everything on the site was made up of nested pages. Ouch.
Tying the content management system to the navigational hierarchy of the site seems a little odd to me. It reminds me of ancient CMSes where everything was managed with an unweildy expanding hierarchical tree on the left hand side.
If I have some events (as a custom post type) on my website, the fact that they live at /events on my site doesn’t necessarily mean that they should be placed in that position within the content hierarchy in the CMS. The same goes with a shop selling products. They might live at /shop but you’re certainly likely to want a dedicated screen showing your products rather than having them mixed in with all your other hierarchical content (which also goes back to the loss of custom admin columns which most shopping systems use extensively).
A great idea, but it seems like it adds unnecessary restrictions to the CMS based on the navigational hierarchy of the site.
This looks like the answer to many issues I’ve faced building sites with multiple content types and complex architecture.
I’ll be putting Hierarchy to good use soon. Great job.
Hey that’s really interesting! I’m going to give it a spin on a site I manage with custom post types madness. Congrats and well done!
You can’t help but bait me with this post 😉
All of this work for Hierarchy is in place to patch a system that manages blog entries (which are just one child of content in CMS). The language you use in the article – Post, Post Type, Page – these are all in the context of a blog. A custom post type is an arbitrary key/value store, with no context or meaning to the entities or values associated with them (I’ll save more of that discussion for another day).
It’s like me taking something like an application that is specifically a commerce engine with products/cart/etc, and re-arranging it for me so it can be turned into a blogging engine. They have specific purposes and use cases.
All of this work, all of the plugins, all of the frustrations, to try and shoehorn WordPress to be an actual CMS. At the end of the day: It’s a great blogging platform.
Hey Nate, you’ve also baited me: which system are you using? Which language is it in? Many times I’ve written about what I’m working on but I’ve yet to see any details behind what you do.
Hierarchy isn’t really doing all the much work to be honest. It does the job of a plugin: add or change functionality. Hierarchy reorganizes some data and puts it in a table view.
If words like “Post”, “Post Type”, and “Page” are only applicable to a blog, what terms are applicable in comparison to a “real” CMS in your opinion? You’ve said a number of times that you’re going to save the issue you have with arbitrary key/value stores in WordPress for another day but I would honestly love to hear more of your thoughts about it.
I realize it’s not completely optimized and full of bleeding edge awesomeness, but WordPress is meant to solve more than one problem. I’m not sure if your core frustration is with WordPress itself or with the idea that something can serve more than one purpose. If it’s the latter, are you writing applications from the ground up, from scratch each and every time? Do you feel the same way about frameworks, toolkits, and libraries?
I think your example of turning an ecommerce platform into a blogging engine is a bit far fetched. A commerce engine is a specialized tool while a “CMS” (regardless of our stances here) is meant to manage content in the general sense of the word.
Hey John thanks for the thoughtful insight. You’re correct, you do lose your admin columns. At this point I’ve envisioned Hierarchy to act as an extremely brief, high level view of your content as a whole. The CPT entries in Hierarchy link off to the WordPress standard CPT index pages, which will bring back the admin columns. Hierarchy doesn’t even support sorting at this point, and that was intended.
My goal here was to make things as easy as possible for my clients. Many times they’re seeing WordPress for the first time, and things like additional admin columns usually confuse them. Including additional admin columns is likely something that wouldn’t be added to Hierarchy for just that reason.
It’s interesting to hear that you feel this direction feels antiquated, perhaps it comes down to a simple difference in preference. I prefer to see my CPTs in context but understand that there are other opinions, which is why I added the option to hide the CPT entries from the Admin Menu as well. That way you could have the “best of both worlds” if you will. Some people could choose to use the Content entry in the Admin Menu while others could use the CPT entries should they be left visible. Just a thought.
Thanks again for the reaction!
Does that plugin support Custom Post Types? I remember seeing it some time ago but last I checked it was only the Pages of your site. Would love to hear that it supports CPTs as well!
That’s an interesting approach, I was looking for that kind of thing.
But the plugin seems focused solely on the admin side (which indeed brings clarity for clients), does it change anything on the published site ? The logic would be to find CPT as sub-pages in the menus and navigation, but apparently that’s not the case. Am I right ? If I am, what would it take to achieve this result ?
[…] the admin menu and placing them into a hierarchical view, shown above. He has written a lengthy post about it over at his site. From the post:In an ideal world, CPT editing would be directly integrated within […]
I will try and reply to several of your questions in specific comments. I may not cover them all here.
1. My role at Within3 means there is a handful of code I can’t make publicly available or share, for business reasons. I’d be glad to show some conceptual examples for things I do. What we do isn’t open source, even our internal gems we build.
2. The language I use is Ruby, but before that was PHP. I have also been working with Python for some machine learning stuff. Even though I moved on from PHP, I still respect it and think it can be organized and architected well.
3. My frustration is not one or the other, it’s a mixture of the two. I think WordPress code is sloppy (Even in recent releases). I understand evolving a product is hard though, so I can suppress that a bit. I don’t think it serves more than one purpose, I think developers have tried to force it to serve more than one purpose. Custom Post Types are not an architecture.
4. Could you explain to me how my example is a bit far fetched? Why couldn’t I turn an e-commerge platform into a blogging engine? E-commerce is comprised of a cart, products, meta data, etc. It is *all just content*, right? WordPress is a specialized tool for blogging. You say ‘content in the general sense of the word’ – so what content is general, and what is not?
Hey Jonathan, this sounds good to me. I’ve been having the same frustrations with the backend and custom post types as well, I’ll give this solution a shot!
[…] the admin menu and placing them into a hierarchical view, shown above. He has written a lengthy post about it over at his site. From the post: In an ideal world, CPT editing would be directly integrated within […]
[…] the admin menu and placing them into a hierarchical view, shown above. He has written a lengthy post about it over at his site. From the post: In an ideal world, CPT editing would be directly integrated within […]
A very interesting approach to simplifying the Dashboard for (first-time) WordPress clients.
Only by playing around with it, will we know how useful it is for us in each individual use case…
Great Job, thanks!
You’re absolutely correct. Hierarchy does nothing insofar as altering your site in any way, it’s just a different way of visualizing the links to edit the site content in the WP Admin.
This is a fix for a problem I didn’t know I had!
Thank you.
Great idea, looking forward to trying this out. Thanks for sharing!
Thanks for all the feedback, Nate!
1) Completely understood that the code you work on is proprietary, I apologize if my reply came across in the way of “show me what you’re working with or else!” While I completely respect that model, it’s in a way a bummer because, even as you said, your internal gems aren’t open source and are likely doing things other people haven’t done before. This isn’t limited to your case, however, it’s the nature of software itself, so I completely understand.
2) I’ve got to be honest and say that you’re probably the first PHP to Ruby convert that still has a place in his heart for PHP done right. That’s great to hear! I think a lot of people forget that PHP is a great ‘beginner’ language due to the low friction in getting up and running. That results in some really junky code that gives PHP a bad name. Many people forget that it’s still possible to write PHP well.
3) I agree with you here, which is why I’ve had a love/hate relationship with Custom Post Types and moreso found a home with Pods. Pods gives your custom data a structure as opposed to an arbitrary entry in one table, and then X entries in a meta table. On the other hand though, Custom Post Types are where WordPress is right now, built into core, so being a WordPress developer I need to work with the tools I’ve been given. Continuing with that, when I put Custom Post Types to use, it’s never with anything high intensity, so downplaying how things are working under the hood and any inherent issues I may have with that, things can get implemented in such a way that will be forward compatible as WordPress matures.
4) I see your point here, but elaborating on the “what content is general?” question: WordPress by default establishes a “content entry” as a title and content block. You can bolt on things like taxonomies and Custom Fields, but out of the box you get a title and content block and have the ability to extend from there. That to me is ‘general content’ whereas with a cart you’ve got something more specialized. For example, trying to convert a ‘product’ into a ‘blog entry’ you’ve got to scale back (e.g. by removing fields specific to product details) as opposed to extend when going the other way. I could be completely wrong here and overly stubborn, but segmenting a Custom Post Type and extending it with product-centric field entries feels more appropriate than taking a product entry page and scaling it back to work as a blog entry.
I think my stance comes back to my satisfaction in WordPress being a framework primed for extension. While yes, it does inherit some non-optimal implementation, I think it’s headed in the right direction for the most part, and provides me a way to build tools for my clients that will help them solve the problems they have with their current system (or lack thereof). I think there will always be tradeoffs when trying to build a system that attempts to solve every problem, but WordPress has done it in such a way that is easy for my clients to use, and exciting for me to put into place.
Again, I hope my original response didn’t come off as hostile, I really enjoy talking shop with someone who isn’t timid about shooting bullet holes in a proposed solution!
Exactly that. Must give this a go tonight 🙂
That plugin does support CPT since awhile ago.
To be honest, that plugin ( CMS tree page view ) is all you need, this plugin ( Hierarchy ) is a little too much in a sense that it involves core. You have to take into account that there is too much overhead in keeping it aligned with core.
My conclusion is this, try to push this concept to be in core. All hierarchy CPT should have this same UI as Page. And while that still not happen yet, keep CMS tree page view alive, it’s leaner and better.
Very cool. I’ve been looking for something exactly like Hierarchy!
Hi Jonathon,
First off, cool plugin! I like the idea of being able to split out the content hierarchy / management from the left-menu. On a lot of our large client sites, it can become rather full with a mixture on content related items and other types on administration pages.
I gave Hierarchy a go, the issue I have, is the small amount of customisation that is possible. IMO Hierarchy would expose a fair amount of configuration through a nice API. For example, I would like to only have a top level Pages link, as this particular site in question has a fair amount of pages,which creates a long list. Also, I don’t necessarily like the idea of having to set the post-type rewrite slug to the ‘parent/slug’ approach, that to me, is kind of mixing the data architecture for the CPTs with how the client wants to visualize the structure.
Ideally, I would like be able to essentially build / modify deeply the hierarchy that is displayed via it’s own API. Still doing all it does automatically of course!
Either way, I think it’s good.
[…] about this new WordPress plugin by Jonathan Christopher called Hierarchy: Hierarchy allows you to (optionally) remove CPT items from the Admin Menu and integrate them […]
Great plug-in! Any plans to include WPML functionality?
Great suggestion! I’ll add it to the feature request list.
[…] Introducing Hierarchy: Even More CMS for WordPress […]
Really cool idea, I’ll definitely try this out.
[…] https://jonchristopher.us/20120105/introducing-hierarchy/ Filed Under: Uncategorized Tagged With: read, wordpress […]
Hey mang! Just wondering how possible it would be to nest cpts under cpts. For example, a post type for restaurants, one for menu items. Then being able to make a menu item a child of a given restaurant, and have that hierarchy visualized on the edit screen.
Hey Ben, I’ve recently run into that myself. I’ll add it to the list to check into.
The only solution so far is an “associations” plug like Posts-2-Posts or the one you worked on a while ago.
The down side is that there’s no visual reflection in the “hierarchy,” which is a good option to have for client driven CMS. Plus, it’s not fully automated. You have to click around.
Being able to add complete restraint (whenever you add a menu item, it always needs a restaurant as a parent) just makes it fool proof.
I feel like all of this should be part of the WP core though… they seem like basic CMS’y type tasks.
Great idea Jonathan, this is something I’ve been thinking on for a while now, a WordPress plugin similar to that of “Structure” for ExpressionEngine http://buildwithstructure.com/. Just curious… Did you get some inspiration from that too?.
WPML would be simply great! Add my vote for that feature request.
Thanks!
I’ve wanted to build the plugin for a number of years now, actually. I have heard of Structure before, and I’m actually good friends with Jack (he lives just a few miles away from me) so you can imagine how pumped I was to see Structure when I first met him a couple years ago! Prior to that I had only heard of EE and not understood much about how it worked. I remember mentioning to him that I had been hoping to build something like that for WP but didn’t have the time. He mentioned he heard rumors of someone already working on it, but I never saw anything come of it. WPML support is definitely on my list, but will take some planning to implement in a useful manner. Looking forward to it.
Thanks for sharing the full story! I’m sure there are many others who have, at least, planned on doing something similar for WordPress… but your friendship with Jack is a clear “competitive advantage”! 🙂
Looking forward to future updates of the Hierarchy plugin!
I really like this plugin, it has cleaned up our admin a lot and makes things much more intuitive. Maybe I’m missing something, though… how do I add a new page with Hierarchy turned on? I’ve figured out how to create new Posts and CPTs, but the new page feature seems to be missing?
Dalton
I just wanted to ask the same question as Dalton, how do you add new pages with Hierarchy turned on?
This is something I’ve been working on but haven’t committed to the repo quite yet. Essentially the idea is to build out the site before turning on Hierarchy as it’s rare that clients would need to directly create a new set of Pages. I understand though, that sometimes that’s the case, so I’m working on just the way to do that. For the time being, you can optionally leave the Pages menu item visible instead of hiding it, but that (in my opinion) would be more confusing to the user. I’m thinking that an Add Page button the Hierarchy page itself will be the likely solution, but haven’t made a decision quite yet. Input welcome!
Is there any way for doing something similar with users? I mean:
Group1:
– boss1: can edit their own boss1 profile + edit user1 & user2 profiles
— user1: can edit only their own profile
— user2: can edit only their own profile
Group2:
– boss2: can edit their own boss2 profile + edit user3 & user4 profiles
— user3: can edit only their own profile
— user4: can edit only their own profile
Thanks!
Not yet, but I’ve got a lot of hopeful ideas for features like this!
I agree with not really wanting the parent/slug thingy but can this plugin work otherwise? If so, I’d definitely prefer to see that solution added…
Have a look at how the plugin mentioned farther up, http://wordpress.org/extend/plugins/cms-tree-page-view/ does it. it is quite cool. The only reason for prefering your plugin is that it adds pages,posts and cpts into one menu.
Apart from that, the other plugin also offers drag and drop sorting function which would be great. Using your method of manually specifying the menu order is quite tiresome 🙁
@Jonathan: I am having trouble subscribing to this post’s comment feed. There is no subscribe to comments checkbox so I tried subscribing to your feed but I am getting an error along the lines: “error on line 17 at column 60: Extra content at the end of the document”
[…] to myself that I was going to pull the trigger on this project and get it started. It was the day Hierarchy was released. My mind had been primed by Jonathan Snook’s release of SMACSS and I was […]
[…] is outstanding, for example. Jonathan Christopher is another one I learned about this year. Hierarchy is gorgeous in its simplicity and clients have enjoyed using […]
[…] Introducing Hierarchy: Even More CMS for WordPress Posted on August 30, 2012 by angelr […]
[…] information on the implementation and workflow changes, check out the screenshots and please see the introduction and the follow-up for […]