Custom Post Types are not Posts

Custom post types are e-commerce products, books, real estate properties and many other things, but the last thing they are, are posts. So why do we continue to use the default posts interface to manage all this awesome additional information we’re storing?

Data.

I was wondering about this issue a while back, as we (Theme Force) use custom post types to store information for a number of the features we maintain (after all, it’s a darn powerful feature of WordPress). Our features are all relatively simple concepts (food, event, slides, etc.), but we were making it far too hard to use. This, simply because we had visually ridiculed information that already had context, to plain old data bound by post_id’s, thus leaving it up to the user to find their way around a table that doesn’t differ much from the SQL one (like the screenshot below):

Mind you, the above was an awesome interface to us, but our users let us know in many ways that this wasn’t working for them (in the worst possible way,  not using it at all). The pretty design, easy accessibility to add/update items was really cool, but it didn’t bring enough structure or hierarchy for the user to even remotely feel productive (see my previous article for more on that, WP Admin is an Experience too.). Imagine you order a hamburger in a restaurant, and 20 minutes later you’re served a plate with each individual ingredient laid out flat on the plate in a uniform manner. Not very appetizing right? Neither are the default one-size-fits-all data tables.

Data + Context.

Fast-forward a few months, we’re now taking the time to build an interface for our food menu custom post type that actually reflects the look and feel of a real menu (seems so logical when you think of it now), bringing together context and hierarchy. It is after all our goal to become the top provider of restaurant websites globally, and not every user is as forgiving and patient as our awesome early adopters have been. Whilst it isn’t complete yet and we’ll certainly have changes to make after it goes live, it’s already miles ahead of its predecessor. Watch the video in full-screen below to get a feel for a different kind of post type.

Click on the full-screen icon in the bottom-right hand corner:

Final Thoughts

Whilst some custom post types can easily use the standard interface, there are a number of cases that could be simplified a whole lot more.  In other environments, you may have no end-users and be the sole person responsible for input, in which case it doesn’t make sense either. However, it’d be really interesting to see where the level of customization goes within the WordPress community when representing custom post types within the admin area. With the already included jQuery UI and a handful of functions (wp_insert_post, wp_update_post, wp_delete_post) you’re already 90% of the way there. Less screen clutter, less clicks for the user and more visual hierarchy all lead to a more awesome experience for your users. What are your thoughts?

  • shawn

    would absolutely LOVE to see some example code as a starting point so that I could learn from it and try my hand at my own interfaces. Do you see that ever happening?

  • Allanlan00

    Why did you say:Custom Post Types are not Posts?juice recipe

  • http://twitter.com/squallstar Nicholas Valbusa

    I just wanna say that I made a CMS named Bancha that manages any content types in a very different way: each content type is defined by an xml scheme, you can see how it works here: http://getbancha.com/features/content-types

  • Anonymous

    Comment removed – For some reason it thinks I’m homesitters…

  • http://www.stuffedweb.com/ Sam

    I would also be interested in seeing that. Interesting post though. Definately something worth thinking about

  • http://twitter.com/ungestaltbar Kai-ser

    This look awesome and I completly agree with the headline of this post.
    So many times I’ ve found myself “abusing” cpt for simple stuff. Like having a “Team/Staff” Page, with an custom page template assigned, but the actual content comes from a custom post type “Staff” with several single posts for each member, just to have some kind of (semantic) structure to make it easier, but you always have to explain to the client that the empty page is just for navigation purpose.
    Much worse in my opinion is to use posts and categories for this, but it’s still pretty popular among many themes.

    This may be a shameless plug, but this problem made me start to develop a different approach which you can see in this ‘proof of concept’ screenr (http://www.screenr.com/Njcs). This demo is “old” but you get the idea.

    Anyway, I also would like to see and read more about your approach and what I didn’t understand yet:
    Is this “visual” menu a add-on for the custom post type? So the single menu items are still managed by a custom post type or can one add,edit,delete everything inside this custom menu page?

  • Streetstealth

    Interesting to see this approach developing in the WordPress community. It’s the concept behind the CMS I use for everything except blogs, ProcessWire.

  • Dave

    Yeah, plus one on being able to see the code as well. This looks really interesting and I’d love to steal bits and pieces!

  • http://HeyDaveCole.com Dave Cole

    Beautiful implementation of the control method for these posts. I remember seeing PODS CMS demoed a few years ago at WordCamp Los Angeles and was blown away with how dynamic a site could become with proper implementation.

    Fast-forward to present-day, and custom post types provide exactly the robust functionality you’re demonstrating; and with the UI wrapper applied it definitely highlights the benefits of developing custom posts that utilize data + context.

    Thanks for sharing, well worth thinking about.

  • http://HeyDaveCole.com Dave Cole

    Beautiful implementation of the control method for these posts. I remember seeing PODS CMS demoed a few years ago at WordCamp Los Angeles and was blown away with how dynamic a site could become with proper implementation.

    Fast-forward to present-day, and custom post types provide exactly the robust functionality you’re demonstrating; and with the UI wrapper applied it definitely highlights the benefits of developing custom posts that utilize data + context.

    Thanks for sharing, well worth thinking about.

  • http://twitter.com/bshumaker Brett Shumaker

    Yes, some example code would be awesome…but it appears it won’t happen since this was posted so long ago. :(