2821 posts
  • Australia
  • Community Moderator
  • Elite Author
  • Author had a Free File of the Month
  • Most Wanted Bounty Winner
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Contributed a Blog Post
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
+10 more
dtbaker Volunteer moderator says

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;
        if($wp_query){
            $wp_query->get_queried_object();
            if($wp_query->queried_object){
                //print_r($wp_query->queried_object);
                $wp_query->queried_object->post_parent = 611;
                $wp_query->post = $wp_query->queried_object;
            }
        }

any ideas? any success?

3365 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Community Moderator
  • Bought between 50 and 99 items
  • Referred more than 2000 users
  • Has been a member for 4-5 years
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
+4 more
sevenspark Volunteer moderator says

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 :P

Chris

2821 posts
  • Australia
  • Community Moderator
  • Elite Author
  • Author had a Free File of the Month
  • Most Wanted Bounty Winner
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Contributed a Blog Post
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
+10 more
dtbaker Volunteer moderator says

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 :(

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

3365 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Community Moderator
  • Bought between 50 and 99 items
  • Referred more than 2000 users
  • Has been a member for 4-5 years
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
+4 more
sevenspark Volunteer moderator says

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?

2821 posts
  • Australia
  • Community Moderator
  • Elite Author
  • Author had a Free File of the Month
  • Most Wanted Bounty Winner
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Contributed a Blog Post
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
+10 more
dtbaker Volunteer moderator says

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:

/wiki/support/documentation-wiki/change-request/

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.

3365 posts
  • Elite Author
  • Sold between 250 000 and 1 000 000 dollars
  • Community Moderator
  • Bought between 50 and 99 items
  • Referred more than 2000 users
  • Has been a member for 4-5 years
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
+4 more
sevenspark Volunteer moderator says

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!

2821 posts
  • Australia
  • Community Moderator
  • Elite Author
  • Author had a Free File of the Month
  • Most Wanted Bounty Winner
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Contributed a Blog Post
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
+10 more
dtbaker Volunteer moderator says

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

803 posts We're a nice team!
  • Author had a File in an Envato Bundle
  • Elite Author
  • Has been a member for 4-5 years
  • Interviewed on the Envato Notes blog
  • Exclusive Author
  • Sold between 100 000 and 250 000 dollars
  • Contributed a Tutorial to a Tuts+ Site
+4 more
ThemeFocus says

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

http://themeforest.net/forums/thread/did-u-appear-have-woff-request-aborted-on-firefox/94171

Thx. :)

2821 posts
  • Australia
  • Community Moderator
  • Elite Author
  • Author had a Free File of the Month
  • Most Wanted Bounty Winner
  • Author had a File in an Envato Bundle
  • Has been a member for 5-6 years
  • Contributed a Blog Post
  • Repeatedly Helped protect Envato Marketplaces against copyright violations
+10 more
dtbaker Volunteer moderator says

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

5075 posts
  • Australia
  • Bought between 100 and 499 items
  • Community Superstar
  • Exclusive Author
  • Has been a member for 3-4 years
  • Interviewed on the Envato Notes blog
  • Microlancer Beta Tester
  • Referred between 1 and 9 users
  • Sold between 1 000 and 5 000 dollars
Australia says

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

by
by
by
by
by
by