WordPress: how to nest Custom Post Type under a Page?


Hi ThemeForest and CodeCanyon people (and WP gurus on the other marketplaces!)

Has anybody successfully nested a Custom Post Type under a standard WordPress page?

I have tried every recommendation on wordpress.stackexchange.com with no success.

I am trying to get all my custom wiki post types to display under the wordpress page /support/documentation-wiki/.

Setting the “slug” on the wiki post type to support/documentation-wiki works in the URL, eg:

page: http://ultimateclientmanager.com/support/documentation-wiki/

wiki: http://ultimateclientmanager.com/support/documentation-wiki/change-request/

but what I’m struggling with is the “current” menu item highlighting. When viewing a wiki page the “Documentation/Wiki” menu and the “Support” menu at the top should be highlighted. I want to avoid hardcoding page id’s (like I’ve done on the forum) as this causes issues when the same theme is used on multisite.

It would also be nice not to have to hardcode the wiki ‘slug’ in the code, just select a page parent.

Setting the wiki post_parent to the page ID in the database does not work and the custom wiki post type is hierarchical. I’ve even tried things like hardcoding the post_parent on page load (this is what wp menu checks when doing its highlighting) but that didn’t work either.

// run in the 'wp' hook when loading a wiki article. 
global $wp_query;
                $wp_query->queried_object->post_parent = 611;
                $wp_query->post = $wp_query->queried_object;

any ideas? any success?


I assume you’re hooking into the nav walker’s menu item classes with the nav_menu_css_class filter?

And are you saying that you can successfully set the parent to a Page ID, but that the standard WordPress current-item-check doesn’t work? Or that the parent relationship isn’t stored in the DB at all?

If the relationship is stored properly, I would just manually check it within that filter (current page parent vs item ID). If you can’t store it properly in the post_parent field, I suppose you could always just create a custom meta field to store a wiki page’s Page parent ID - not as pretty, but there shouldn’t be any restrictions on that.

Not sure if that helps as I’m not 100% sure what point you’re at on the problem. Also, it’s late here, so maybe I misinterpreted this entirely :stuck_out_tongue:



Yep it saves post_parent in the db just fine, but it treats the “wiki” post_parent different to a “page” post_parent when generating permalinks and automatically highlighting menu items (even when a wiki post_parent points to a page).

Yep manually highlighting menu items is easy when hardcoding the page ID’s eg:

add_filter('nav_menu_css_class' , 'special_nav_class_bbpress' , 10 , 2);
function special_nav_class_bbpress($classes, $item){
         // highlight menu item ID 456 when viewing page ID 123.
         if(get_the_ID()==123 && isset($item->ID) && $item->ID==456 )
            $classes[] = 'active';

but I’m trying to avoid any hardcoding of ID’s/slugs. Basically trying to trick wordpress into thinking a “wiki” post type is a normal “page” when it does the behind the scenes magic (permalink generation and menu highlighting). Still digging through the WP code, but so far this low level stuff doesn’t seem like it has any available hooks to mess with :frowning:

more on stackexchange: http://wordpress.stackexchange.com/questions/94517/custom-post-type-nest-under-a-normal-wordpress-page - hopefully someone can assist


I’m probably missing something, but can’t you just test whether the parent_id = the current menu item’s post ID?

add_filter('nav_menu_css_class' , 'special_nav_class_bbpress' , 10 , 2);
function special_nav_class_bbpress($classes, $item){
   global $post;
   if( $post->post_type == 'wiki' && $post->parent_id == $item->object_id )
      $classes[] = 'active';
   return $classes;

I believe the object_id property contains the ID of the post to which the menu item links. Probably need to add some existence checks in there, but I think that’s the basic idea. You can also test $item->menu_item_parent == 0 to see if you’re checking a top level menu item, if that’s what you want to target.

Is that useful?


Almost! The issue is when I select a parent on a “wiki” the URL changes from to:

/support/documentation-wiki/change-request/ (no parent selected)

/support/documentation-wiki/support/documentation-wiki/change-request/ (parent selected)

and gives a 404 error lol

If the custom post type rewrite slug is changed from ‘support/documentation-wiki’ to just ‘wiki’ then the generated url looks like this:


and this still gives a 404 error, and an incorrect url.

So I’m trying to tackle the permalink generation when a parent is selected, along with current menu highlighting. I think menu highlighting will be easier once URLs are generated successfully.

Currently all wiki articles have no post parent, that’s the only way I can get it working.


Personally I think I would bypass the issue and use a custom meta field to set the post parent, e.g. “Parent Page” (either set the page ID in the field, or write a custom meta box that allows you to select a post/Page as a parent. Then test against that meta value. This way you can leave the standard post parent field empty and avoid the rewrite issue. Not as clean as it could be, but it should work.

Gotta get some sleep - good luck!


Good idea, I’ll give that a shot and try to tackle manually highlighting multi level page parents as well.


@sevenspark @dtbaker I have a question about .woff, did u before appear it?

Thx. :slight_smile:


Turns out it’s impossible to nest multiple post_types using the built in post_parent wp feature.

The wordpress get_page_by_path() will only return a valid page if all of the nested items are of the same post_type. There are no filters or tricks or hooks at this low level. Meh


Its above my head but how come you cant use data attributes and add them dynamically. as in data-id


Got it working. Hooked into the ‘query’ filter and regex’d the raw wordpress SQL so it would support multiple nested post types.


but now wordpress will:

  • generate nice URLs, like /pages/sub-page/custom-post-type (eg: http://ultimateclientmanager.com/support/documentation-wiki/change-request/ )
  • automatically highlight any ancestor menus ( see left and top )
  • allow custom post types to be grouped under multiple different pages, which would not be nice via the old filter nav css method



Haha yeah, that is pretty nasty. Glad you found a solution! :slight_smile: