How to handle a hierarchy with custom post types

When planning more complex WordPress sites, I try to think of the page/url hierarchy in terms of the default WordPress Database Schema. Then determine the best URL rewrite scheme and data structure. Very generally, I find that data objects most important to the user should exist as a custom post type or a post object, relationships between custom posts should use custom taxonomies and unique values should be stored in postmeta.

More specifically, if I was offering products with version updates, I might create a custom post type for each product (assuming a limited number of total products with version updates) and create a new post for each new release (WP stores posts chronologically by default, so multiple releases should work well). In other words, each new release would exist as a single post under the custom post type and each new post will contain the details of that release. You could then display the details for the most recent post on a page for the custom post type. By forcing each post to be paginated, you should also be able to have separate URL’s for features, etc., and you should be able to make them pretty by rewriting the URL.

Visually:

/products/%custom-post-type%/
/products/product-a/

/products/%custom-post-type%/archive/
/products/product-a/releases/

/products/%custom-post-type%/%post-name%/
/products/product-a/release-xx/

/products/%custom-post-type%/%post-name%/page/2/
/products/product-a/release-xx/features/

Leave a Comment